From speermint-bounces@ietf.org Mon May 01 15:36:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaeC0-0000LJ-Vz; Mon, 01 May 2006 15:36:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaeBz-0000LE-MV for speermint@ietf.org; Mon, 01 May 2006 15:36:23 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaeBy-0000sz-GB for speermint@ietf.org; Mon, 01 May 2006 15:36:23 -0400 Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.19394563; Mon, 01 May 2006 15:35:59 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 May 2006 15:35:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 May 2006 15:35:58 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7305248110@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF Meeting Survey Thread-Index: AcZtM2XWr5/vMA4YRHK/lkUctPqndwAIucuQ From: "Livingood, Jason" To: X-OriginalArrivalTime: 01 May 2006 19:35:58.0946 (UTC) FILETIME=[78E3FC20:01C66D56] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Speermint] FW: IETF Meeting Survey X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org For those of you who attended the IETF meeting in Dallas, there is a survey online. Please share your feedback with the IETF so the leadership knows what worked, what did not, and what to improve. Thanks Jason=20 -----Original Message----- From: Ray Pelletier [mailto:rpelletier@isoc.org]=20 Sent: Monday, May 01, 2006 11:25 AM Those interested in taking the survey can find it at: http://www.surveymonkey.com/s.asp?u=3D649182049947 Thanks Ray Pelletier IETF Admininstrative Director _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon May 08 16:55:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdClC-0001r7-2e; Mon, 08 May 2006 16:55:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdClB-0001qx-68 for speermint@ietf.org; Mon, 08 May 2006 16:55:17 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdClA-000059-UU for speermint@ietf.org; Mon, 08 May 2006 16:55:17 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 08 May 2006 13:55:16 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,102,1146466800"; d="scan'208"; a="549147578:sNHT19618896" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 May 2006 16:55:15 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804477A56@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-penno-message-flows-02.txt Thread-Index: AcZtM2XWr5/vMA4YRHK/lkUctPqndwAIucuQAWLWo6A= From: "Reinaldo Penno" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Speermint] I-D ACTION:draft-penno-message-flows-02.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SPEERMINT Routing Architecture Message Flows Author(s) : R. Penno, et al. Filename : draft-penno-message-flows-02.txt Pages : 27 Date : 2006-5-8 =09 This draft provides the message flows associated with the SPEERMINT=20 routing architecture. We show message flows in several peering=20 scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-penno-message-flows-02.txt _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon May 08 16:55:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdCkZ-0001nt-R3; Mon, 08 May 2006 16:54:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdCkY-0001nm-HV for speermint@ietf.org; Mon, 08 May 2006 16:54:38 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdCkX-0008Vi-9F for speermint@ietf.org; Mon, 08 May 2006 16:54:38 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 08 May 2006 13:54:33 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,102,1146466800"; d="scan'208"; a="549147441:sNHT20195676" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 May 2006 16:54:33 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804477A55@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-khan-ip-serv-peer-arch-01.txt Thread-Index: AcZtM2XWr5/vMA4YRHK/lkUctPqndwAIucuQAWLN2DA= From: "Reinaldo Penno" To:From speermint-bounces@ietf.org Mon May 08 16:55:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdClC-0001r7-2e; Mon, 08 May 2006 16:55:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdClB-0001qx-68 for speermint@ietf.org; Mon, 08 May 2006 16:55:17 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdClA-000059-UU for speermint@ietf.org; Mon, 08 May 2006 16:55:17 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 08 May 2006 13:55:16 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,102,1146466800"; d="scan'208"; a="549147578:sNHT19618896" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 May 2006 16:55:15 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804477A56@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-penno-message-flows-02.txt Thread-Index: AcZtM2XWr5/vMA4YRHK/lkUctPqndwAIucuQAWLWo6A= From: "Reinaldo Penno" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Speermint] I-D ACTION:draft-penno-message-flows-02.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SPEERMINT Routing Architecture Message Flows Author(s) : R. Penno, et al. Filename : draft-penno-message-flows-02.txt Pages : 27 Date : 2006-5-8 =09 This draft provides the message flows associated with the SPEERMINT=20 routing architecture. We show message flows in several peering=20 scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-penno-message-flows-02.txt _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon May 08 16:55:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdCkZ-0001nt-R3; Mon, 08 May 2006 16:54:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdCkY-0001nm-HV for speermint@ietf.org; Mon, 08 May 2006 16:54:38 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdCkX-0008Vi-9F for speermint@ietf.org; Mon, 08 May 2006 16:54:38 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 08 May 2006 13:54:33 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,102,1146466800"; d="scan'208"; a="549147441:sNHT20195676" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 May 2006 16:54:33 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804477A55@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-khan-ip-serv-peer-arch-01.txt Thread-Index: AcZtM2XWr5/vMA4YRHK/lkUctPqndwAIucuQAWLN2DA= From: "Reinaldo Penno" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Speermint] I-D ACTION:draft-khan-ip-serv-peer-arch-01.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SPEERMINT Peering Architecture Author(s) : S. Khan, et al. Filename : draft-khan-ip-serv-peer-arch-01.txt Pages : 12 Date : 2006-5-8 =09 This document defines a SPEERMINT peering reference architecture, its=20 functional components and peering interface functions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-khan-ip-serv-peer-arch-01.txt _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Speermint] I-D ACTION:draft-khan-ip-serv-peer-arch-01.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SPEERMINT Peering Architecture Author(s) : S. Khan, et al. Filename : draft-khan-ip-serv-peer-arch-01.txt Pages : 12 Date : 2006-5-8 =09 This document defines a SPEERMINT peering reference architecture, its=20 functional components and peering interface functions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-khan-ip-serv-peer-arch-01.txt _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 09 02:05:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdLKh-00062f-NR; Tue, 09 May 2006 02:04:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdLKg-00062a-AW for speermint@ietf.org; Tue, 09 May 2006 02:04:30 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdLKf-0004Rx-26 for speermint@ietf.org; Tue, 09 May 2006 02:04:30 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 08 May 2006 23:04:28 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,103,1146466800"; d="scan'208"; a="545298235:sNHT20241132" Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 9 May 2006 02:04:25 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804477AA3@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-penno-message-flows-02.txt Thread-Index: AcZtM2XWr5/vMA4YRHK/lkUctPqndwAIucuQAXX6mpA= From: "Reinaldo Penno" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Speermint] I-D ACTION:draft-penno-message-flows-02.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SPEERMINT Routing Architecture Message Flows Author(s) : R. Penno, et al. Filename : draft-penno-message-flows-02.txt Pages : 27 Date : 2006-5-8 =09 This draft provides the message flows associated with the SPEERMINT=20 routing architecture. We show message flows in several peering=20 scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-penno-message-flows-02.txt _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu May 11 10:48:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCS7-0007nC-Qt; Thu, 11 May 2006 10:47:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCS6-0007n7-Al for speermint@ietf.org; Thu, 11 May 2006 10:47:42 -0400 Received: from mercury.sunrocket.com ([208.50.38.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeCS5-0005CX-3q for speermint@ietf.org; Thu, 11 May 2006 10:47:42 -0400 Received: (qmail 8008 invoked from network); 11 May 2006 14:47:35 -0000 Received: from ip68-100-79-176.dc.dc.cox.net (HELO [192.168.0.2]) (gkulshreshtha@[68.100.79.176]) (envelope-sender ) by mercury.sunrocket.com (qmail-ldap-1.03) with SMTP for ; 11 May 2006 14:47:35 -0000 Message-ID: <44634E83.70605@sunrocket.com> Date: Thu, 11 May 2006 10:47:31 -0400 From: Gaurav Kulshreshtha Organization: SunRocket Inc. User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Reinaldo Penno Subject: Re: [Speermint] I-D ACTION:draft-penno-message-flows-02.txt References: <9BD5D7887235424FA97DFC223CAE3C2804477AA3@proton.jnpr.net> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2804477AA3@proton.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gaurav@sunrocket.com List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Reinaldo, Quick comment Reference for SBC is set to 6 should be 9 under the description for collapsed model of peering The document describes Static and On-demand models for peering. On-demand assumes a DNS query mechanism to find out the right peer. I think its possible that in future we may have routing protocols for Layer-5 addresses. There may be some changes in order for URI naming scheme to give it more structure. Cheers, Gaurav Kulshreshtha Reinaldo Penno wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : SPEERMINT Routing Architecture Message Flows > Author(s) : R. Penno, et al. > Filename : draft-penno-message-flows-02.txt > Pages : 27 > Date : 2006-5-8 > > This draft provides the message flows associated with the SPEERMINT > routing architecture. We show message flows in several peering > scenarios. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-penno-message-flows-02.txt > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 17 10:37:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgN9c-0004AS-GA; Wed, 17 May 2006 10:37:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgN9b-0004AN-Kc for speermint@ietf.org; Wed, 17 May 2006 10:37:35 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgN9a-0004MB-7Z for speermint@ietf.org; Wed, 17 May 2006 10:37:35 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k4HEbUli029875 for ; Wed, 17 May 2006 07:37:30 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k4HEbTqt029874 for speermint@ietf.org; Wed, 17 May 2006 07:37:29 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 17 May 2006 07:37:29 -0700 From: David Meyer To: speermint@ietf.org Message-ID: <20060517143728.GA29809@1-4-5.net> Mime-Version: 1.0 User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Subject: [Speermint] FYI -- [rpelletier@isoc.org: Last Call: Proposed 2008 - 2010 IETF Meeting Calendar]] X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0511638198==" Errors-To: speermint-bounces@ietf.org --===============0511638198== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable ----- Forwarded message from Ray Pelletier ----- >=20 > From: Ray Pelletier > To: ietf@ietf.org, iesg@ietf.org, iab@ietf.org, wgchairs@ietf.org > Cc:=20 > Subject: Last Call: Proposed 2008 - 2010 IETF Meeting Calendar > Date: Wed, 17 May 2006 06:58:36 -0400 >=20 > All; >=20 > This is a 1 week Last Call for feedback on Version 01 proposed 2008 -=20 > 1010 IETF Meeting dates. The IAOC anticipates taking action to formally= =20 > adopt dates on 25 May 2006. These dates differ from the originally=20 > proposed dates based upon community feedback, a review of meeting dates= =20 > of those organizations on the Clash List and maintenance of a reasonably= =20 > similar period between meetings. While every effort was made to avoid=20 > conflicts where known, it was not always possible with those=20 > organizations in the "should avoid" category. Your feedback to=20 > iad@ietf.org on conflicts with these dates would be appreciated. >=20 > Proposed 2008 - 2010 meeting dates: >=20 > 2008 >=20 > IETF 71 Mar 30 - Apr 4 >=20 > IETF 72 Jul 27 - Aug 1 >=20 > IETF 73 Dec 7 - 12 >=20 > 2009 >=20 > IETF 74 Mar 22 - 27 >=20 > IETF 75 Aug 2 - 7 >=20 > IETF 76 Dec 6 - 11 >=20 > 2010 >=20 > IETF 77 Mar 28 - Apr 2 >=20 > IETF 78 Jul 25 - 30 >=20 > IETF 79 Dec 5 - 10 >=20 > Our findings of the schedule of other organization's meetings can be=20 > found at: http://www.ietf.org/meetings/events.cal.html . >=20 > Thanks for your assistance. >=20 > Ray Pelletier > IAD >=20 ----- End forwarded message ----- --zhXaljGHf11kAtnf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEazUoORgD1qCZ2KcRAh+SAJ9Mpc5kzdvatAs7j+OniNwR/137GACeOPrJ efEGgTd1PmNLZkjZWZwsfME= =LT0J -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf-- --===============0511638198== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0511638198==-- From speermint-bounces@ietf.org Wed May 17 15:13:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgRS3-0002nj-JW; Wed, 17 May 2006 15:12:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgRS2-0002ne-Jg for speermint@ietf.org; Wed, 17 May 2006 15:12:54 -0400 Received: from outbound-res.frontbridge.com ([63.161.60.49] helo=outbound2-res-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgRS1-0002Lp-80 for speermint@ietf.org; Wed, 17 May 2006 15:12:54 -0400 Received: from outbound2-res.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-res-R.bigfish.com (Postfix) with ESMTP id 2729E5E93AF; Wed, 17 May 2006 19:12:53 +0000 (UTC) Received: from mail14-res-R.bigfish.com (unknown [172.18.16.1]) by outbound2-res.bigfish.com (Postfix) with ESMTP id 1F4575E939B; Wed, 17 May 2006 19:12:53 +0000 (UTC) Received: from mail14-res.bigfish.com (localhost.localdomain [127.0.0.1]) by mail14-res-R.bigfish.com (Postfix) with ESMTP id 13EDD580AA0; Wed, 17 May 2006 19:12:53 +0000 (UTC) X-BigFish: V Received: by mail14-res (MessageSwitch) id 11478931735729_29649; Wed, 17 May 2006 19:12:53 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail14-res.bigfish.com (Postfix) with ESMTP id D81F9580949; Wed, 17 May 2006 19:12:52 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k4HJCpAg014905; Wed, 17 May 2006 14:12:52 -0500 (CDT) Received: from pdawg06a.ad.sprint.com (PDAWG06A.corp.sprint.com [10.122.2.33]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k4HJCpw17511; Wed, 17 May 2006 14:12:51 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.244]) by pdawg06a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 14:12:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 17 May 2006 14:12:16 -0500 Message-ID: <978886E57CC1D64EAFAC157B98E36F9E08BF9184@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwA== From: "Khan, Sohel Q [CTO]" To: "David Meyer" , X-OriginalArrivalTime: 17 May 2006 19:12:15.0960 (UTC) FILETIME=[CF558D80:01C679E5] X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Subject: [Speermint] Updated Draft: SPEERMINT Peering Architecture X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1422961373==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============1422961373== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C679E5.CF17BBC2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C679E5.CF17BBC2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We submitted the updated SPEERMINT Peering Architecture draft. This update includes many of your input from the last IETF meeting. Please review and provide input in the mailing list http://www.ietf.org/internet-drafts/draft-khan-ip-serv-peer-arch-02.txt ------_=_NextPart_001_01C679E5.CF17BBC2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Updated Draft: SPEERMINT Peering Architecture

We submitted the updated SPEERMINT = Peering Architecture draft.
This update includes many of your = input from the last IETF meeting.

Please review and provide input in the = mailing list


http://www.ietf.org/internet-drafts/draft-khan-ip-serv-peer-arch-02.= txt


------_=_NextPart_001_01C679E5.CF17BBC2-- --===============1422961373== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============1422961373==-- From speermint-bounces@ietf.org Wed May 17 15:38:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgRq9-0003cz-8V; Wed, 17 May 2006 15:37:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgRq8-0003ct-8x for speermint@ietf.org; Wed, 17 May 2006 15:37:48 -0400 Received: from [205.151.208.34] (helo=fw.tr.xittelecom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgRq5-0003d0-SW for speermint@ietf.org; Wed, 17 May 2006 15:37:48 -0400 Received: from [192.168.2.139] (helo=gestionfm) by fw.tr.xittelecom.com with esmtp (Exim 3.36 #1 (Debian)) id 1Frh72-0006rV-00; Sat, 17 Jun 2006 16:09:44 -0400 From: "Francois D. Menard" To: "'Khan, Sohel Q [CTO]'" , "'David Meyer'" , Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Wed, 17 May 2006 15:37:24 -0400 Message-ID: <001301c679e9$55d52250$8b02a8c0@gestionfm> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQww In-Reply-To: <978886E57CC1D64EAFAC157B98E36F9E08BF9184@PLSWB08C.ad.sprint.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Just completed reading 02 and I have the following proposal: =20 1) With regards to SIP interoperability in section 4.3, I would like to mention that in Canada, we have agreed at the CISC NTWG (http://www.crtc.gc.ca/cisc/eng/cisf3d0.htm) that that the following = RFCs are sufficient to implement the equivalement of the CCS7 minimum message set: =20 http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTRE035B.doc =20 SIP + http://www.ietf.org/rfc/rfc3323.txt http://www.ietf.org/rfc/rfc3325.txt =20 I therefore propose that we state the following in the document under = SIP interoperability in section 4.3: It is expected that the level of SIP interoperability achieved between = two service providers will arise out of the outcome of market-based = bilateral negociations.=20 However, it is expected that a level of interoperability equivalent to = the SS7 minimum message set of the conventional PSTN will require service prociders to implement SF that SHALL BE compliant with both, RFC 3323 (A Privacy Mechanism for the Session Initiation Protocol) and RFC 3325 = (Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks). -=3DFrancois=3D- -- Fran=E7ois D. M=E9nard Projet manager Xittel telecommunications inc. 1350 Royale #800 Trois-Rivieres, QC, G9A 4J4 Canada fmenard@xittel.net Tel: (819) 374-2556 ext. 268 Fax: (819) 374-0395 Cell: (819) 692-1383 =20 ________________________________ From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com]=20 Sent: 17 mai 2006 15:12 To: David Meyer; speermint@ietf.org Subject: [Speermint] Updated Draft: SPEERMINT Peering Architecture We submitted the updated SPEERMINT Peering Architecture draft.=20 This update includes many of your input from the last IETF meeting.=20 Please review and provide input in the mailing list=20 http://www.ietf.org/internet-drafts/draft-khan-ip-serv-peer-arch-02.txt = =20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 17 15:50:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgS28-0000CP-FT; Wed, 17 May 2006 15:50:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgS20-0000A9-V9; Wed, 17 May 2006 15:50:04 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgS1y-0004Ow-Dq; Wed, 17 May 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k4HJo21I013836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 17 May 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FgS1y-0002Aw-5Z; Wed, 17 May 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 17 May 2006 15:50:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-terminology-00.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : SPEERMINT Terminology Author(s) : D. Meyer Filename : draft-ietf-speermint-terminology-00.txt Pages : 12 Date : 2006-5-17 This document defines the terminology that is to be used by the Session PEERing for Multimedia INTerconnect Working Group (SPEERMINT). It has as its primary objective to focus the working group during its discussions, and when writing requirements, gap analysis and other solutions oriented documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speermint-terminology-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speermint-terminology-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-17110144.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-terminology-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-terminology-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-17110144.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --NextPart-- From speermint-bounces@ietf.org Wed May 17 16:51:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgSzN-0003gb-RT; Wed, 17 May 2006 16:51:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgSzM-0003fn-5H for speermint@ietf.org; Wed, 17 May 2006 16:51:24 -0400 Received: from outbound-haw.frontbridge.com ([12.129.219.97] helo=outbound5-haw-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgSzJ-0001Li-NZ for speermint@ietf.org; Wed, 17 May 2006 16:51:24 -0400 Received: from outbound5-haw.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound5-haw-R.bigfish.com (Postfix) with ESMTP id 4476515E06ED; Wed, 17 May 2006 20:51:21 +0000 (UTC) Received: from mail58-haw-R.bigfish.com (unknown [192.168.51.1]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by outbound5-haw.bigfish.com (Postfix) with ESMTP id 3B95A15E06AB; Wed, 17 May 2006 20:51:21 +0000 (UTC) Received: from mail58-haw.bigfish.com (localhost.localdomain [127.0.0.1]) by mail58-haw-R.bigfish.com (Postfix) with ESMTP id 26A4267C608; Wed, 17 May 2006 20:51:21 +0000 (UTC) X-BigFish: V Received: by mail58-haw (MessageSwitch) id 1147899081111283_3650; Wed, 17 May 2006 20:51:21 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail58-haw.bigfish.com (Postfix) with ESMTP id ED86867C6A7; Wed, 17 May 2006 20:51:20 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id k4HKoTgI001514; Wed, 17 May 2006 15:50:55 -0500 (CDT) Received: from pdawg05a.ad.sprint.com (PDAWG05A.corp.sprint.com [10.122.2.38]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k4HKoSw12771; Wed, 17 May 2006 15:50:28 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.244]) by pdawg05a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 15:49:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Wed, 17 May 2006 15:49:52 -0500 Message-ID: <978886E57CC1D64EAFAC157B98E36F9E08BF95AB@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwA= From: "Khan, Sohel Q [CTO]" To: "Francois D. Menard" , "David Meyer" , X-OriginalArrivalTime: 17 May 2006 20:49:55.0920 (UTC) FILETIME=[74247D00:01C679F3] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Franois, Thanks for the input. Question: is it necessary to mention SS7 = specifically?=20 -----Original Message----- From: Francois D. Menard [mailto:fmenard@xittelecom.com]=20 Sent: Wednesday, May 17, 2006 2:37 PM To: Khan, Sohel Q [CTO]; 'David Meyer'; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Just completed reading 02 and I have the following proposal: =20 1) With regards to SIP interoperability in section 4.3, I would like to = mention that in Canada, we have agreed at the CISC NTWG (http://www.crtc.gc.ca/cisc/eng/cisf3d0.htm) that that the following = RFCs are sufficient to implement the equivalement of the CCS7 minimum = message set: =20 http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTRE035B.doc =20 SIP + http://www.ietf.org/rfc/rfc3323.txt http://www.ietf.org/rfc/rfc3325.txt =20 I therefore propose that we state the following in the document under = SIP interoperability in section 4.3: It is expected that the level of SIP interoperability achieved between = two service providers will arise out of the outcome of market-based = bilateral negociations.=20 However, it is expected that a level of interoperability equivalent to = the SS7 minimum message set of the conventional PSTN will require service = prociders to implement SF that SHALL BE compliant with both, RFC 3323 (A = Privacy Mechanism for the Session Initiation Protocol) and RFC 3325 = (Private Extensions to the Session Initiation Protocol (SIP) for = Asserted Identity within Trusted Networks). -=3DFrancois=3D- -- Fran=E7ois D. M=E9nard Projet manager Xittel telecommunications inc. 1350 Royale #800 Trois-Rivieres, QC, G9A 4J4 Canada fmenard@xittel.net Tel: (819) 374-2556 ext. 268 Fax: (819) 374-0395 Cell: (819) 692-1383 =20 ________________________________ From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] Sent: 17 mai 2006 15:12 To: David Meyer; speermint@ietf.org Subject: [Speermint] Updated Draft: SPEERMINT Peering Architecture We submitted the updated SPEERMINT Peering Architecture draft.=20 This update includes many of your input from the last IETF meeting.=20 Please review and provide input in the mailing list=20 http://www.ietf.org/internet-drafts/draft-khan-ip-serv-peer-arch-02.txt = =20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 17 17:10:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgTHG-0003gf-PV; Wed, 17 May 2006 17:09:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgTHF-0003ga-O1 for speermint@ietf.org; Wed, 17 May 2006 17:09:53 -0400 Received: from [205.151.208.34] (helo=fw.tr.xittelecom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgTHE-0002Oc-CY for speermint@ietf.org; Wed, 17 May 2006 17:09:53 -0400 Received: from [192.168.2.139] (helo=gestionfm) by fw.tr.xittelecom.com with esmtp (Exim 3.36 #1 (Debian)) id 1FriYM-0006tI-00; Sat, 17 Jun 2006 17:42:02 -0400 From: "Francois D. Menard" To: "'Khan, Sohel Q [CTO]'" , "'David Meyer'" , Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Wed, 17 May 2006 17:09:48 -0400 Message-ID: <005101c679f6$3b175b60$8b02a8c0@gestionfm> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEA== In-Reply-To: <978886E57CC1D64EAFAC157B98E36F9E08BF95AB@PLSWB08C.ad.sprint.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I would, because ultimately, the minimum level of interoperability will = be (at least in Canada) mandated by the regulator (here, the CRTC). So therefore, the baseline comparison is what goes on today in the SS7 = PSTN.=20 F. -- Fran=E7ois D. M=E9nard Charg=E9 de projet Xit t=E9l=E9com inc. 1350 rue Royale #800 Trois-Rivi=E8res, QC, G9A 4J4 Canada fmenard@xittelecom.com Tel: (819) 374-2556 ext. 268 Fax: (819) 374-0395 Cell: (819) 692-1383 =20 -----Original Message----- From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com]=20 Sent: 17 mai 2006 16:50 To: Francois D. Menard; David Meyer; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Franois, Thanks for the input. Question: is it necessary to mention SS7 = specifically? -----Original Message----- From: Francois D. Menard [mailto:fmenard@xittelecom.com] Sent: Wednesday, May 17, 2006 2:37 PM To: Khan, Sohel Q [CTO]; 'David Meyer'; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Just completed reading 02 and I have the following proposal: =20 1) With regards to SIP interoperability in section 4.3, I would like to mention that in Canada, we have agreed at the CISC NTWG (http://www.crtc.gc.ca/cisc/eng/cisf3d0.htm) that that the following = RFCs are sufficient to implement the equivalement of the CCS7 minimum message set: =20 http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTRE035B.doc =20 SIP + http://www.ietf.org/rfc/rfc3323.txt http://www.ietf.org/rfc/rfc3325.txt =20 I therefore propose that we state the following in the document under = SIP interoperability in section 4.3: It is expected that the level of SIP interoperability achieved between = two service providers will arise out of the outcome of market-based = bilateral negociations.=20 However, it is expected that a level of interoperability equivalent to = the SS7 minimum message set of the conventional PSTN will require service prociders to implement SF that SHALL BE compliant with both, RFC 3323 (A Privacy Mechanism for the Session Initiation Protocol) and RFC 3325 = (Private Extensions to the Session Initiation Protocol (SIP) for Asserted = Identity within Trusted Networks). -=3DFrancois=3D- -- Fran=E7ois D. M=E9nard Projet manager Xittel telecommunications inc. 1350 Royale #800 Trois-Rivieres, QC, G9A 4J4 Canada fmenard@xittel.net Tel: (819) 374-2556 ext. 268 Fax: (819) 374-0395 Cell: (819) 692-1383 =20 ________________________________ From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] Sent: 17 mai 2006 15:12 To: David Meyer; speermint@ietf.org Subject: [Speermint] Updated Draft: SPEERMINT Peering Architecture We submitted the updated SPEERMINT Peering Architecture draft.=20 This update includes many of your input from the last IETF meeting.=20 Please review and provide input in the mailing list=20 http://www.ietf.org/internet-drafts/draft-khan-ip-serv-peer-arch-02.txt = =20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu May 18 15:08:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgnrB-00073b-No; Thu, 18 May 2006 15:08:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgnrA-00073V-96 for speermint@ietf.org; Thu, 18 May 2006 15:08:20 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgnr7-0005J5-Ma for speermint@ietf.org; Thu, 18 May 2006 15:08:20 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 18 May 2006 12:08:17 -0700 X-IronPort-AV: i="4.05,142,1146466800"; d="scan'208"; a="1808711067:sNHT32677400" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k4IJ8GC1004096; Thu, 18 May 2006 12:08:16 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4IJ8DsH000751; Thu, 18 May 2006 12:08:14 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 May 2006 15:08:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Thu, 18 May 2006 15:08:12 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3017E5950@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjA From: "Michael Hammer \(mhammer\)" To: "Francois D. Menard" , "Khan, Sohel Q [CTO]" , "David Meyer" , X-OriginalArrivalTime: 18 May 2006 19:08:13.0891 (UTC) FILETIME=[69768130:01C67AAE] DKIM-Signature: a=rsa-sha1; q=dns; l=4511; t=1147979296; x=1148843296; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Updated=20Draft=3A=20SPEERMINT=20Peering=20Archite cture; X=v=3Dcisco.com=3B=20h=3DNbl2y40gM6uyT9ufgAxvd/Fmy10=3D; b=WLdL7fIakTgeWB+2Zpm/hZT2UqXClQ98y2BwwDZe2T6dcKvDd+V9N+4eIVdjvep1FBOEW5vq Y4RZdnqajurGW3fpd4phs+z+3LgcaKy6unu8GTlqtqJr5NyUwtGiJRc9; Authentication-Results: sj-dkim-5.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Francois, I understand the reasoning, but any mention of the PSTN tends to raise = red flags. It also seems to duplicate other efforts inside IETF and = out: The SIP WG is trying to compile a document defining interoperability for = SIP. I see that as one form of federation. Such an RFC (when it = appears) could be cited. =20 ATIS is planning an ANSI standard that could also be cited. That may = influence the CRTC. I think all we need is for Speermint to have a mechanisms to identify = such reference points. It's a measure of indirection. I don't think we = need to compile those (dare I say) profiles in Speermint. Mike > -----Original Message----- > From: Francois D. Menard [mailto:fmenard@xittelecom.com]=20 > Sent: Wednesday, May 17, 2006 5:10 PM > To: 'Khan, Sohel Q [CTO]'; 'David Meyer'; speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > I would, because ultimately, the minimum level of=20 > interoperability will be (at least in Canada) mandated by the=20 > regulator (here, the CRTC). So therefore, the baseline=20 > comparison is what goes on today in the SS7 PSTN.=20 >=20 > F. > -- > Fran=E7ois D. M=E9nard > Charg=E9 de projet > Xit t=E9l=E9com inc. > 1350 rue Royale #800 > Trois-Rivi=E8res, QC, G9A 4J4 > Canada > fmenard@xittelecom.com > Tel: (819) 374-2556 ext. 268 > Fax: (819) 374-0395 > Cell: (819) 692-1383 > =20 >=20 > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: 17 mai 2006 16:50 > To: Francois D. Menard; David Meyer; speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > Franois, >=20 > Thanks for the input. Question: is it necessary to mention=20 > SS7 specifically? >=20 >=20 > -----Original Message----- > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > Sent: Wednesday, May 17, 2006 2:37 PM > To: Khan, Sohel Q [CTO]; 'David Meyer'; speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > Just completed reading 02 and I have the following proposal: > =20 > 1) With regards to SIP interoperability in section 4.3, I=20 > would like to mention that in Canada, we have agreed at the CISC NTWG > (http://www.crtc.gc.ca/cisc/eng/cisf3d0.htm) that that the=20 > following RFCs are sufficient to implement the equivalement=20 > of the CCS7 minimum message > set: > =20 > http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTRE035B.doc > =20 > SIP + > http://www.ietf.org/rfc/rfc3323.txt > http://www.ietf.org/rfc/rfc3325.txt > =20 > I therefore propose that we state the following in the=20 > document under SIP interoperability in section 4.3: >=20 > It is expected that the level of SIP interoperability=20 > achieved between two service providers will arise out of the=20 > outcome of market-based bilateral negociations.=20 >=20 > However, it is expected that a level of interoperability=20 > equivalent to the > SS7 minimum message set of the conventional PSTN will require=20 > service prociders to implement SF that SHALL BE compliant=20 > with both, RFC 3323 (A Privacy Mechanism for the Session=20 > Initiation Protocol) and RFC 3325 (Private Extensions to the=20 > Session Initiation Protocol (SIP) for Asserted Identity=20 > within Trusted Networks). >=20 > -=3DFrancois=3D- > -- > Fran=E7ois D. M=E9nard > Projet manager > Xittel telecommunications inc. > 1350 Royale #800 > Trois-Rivieres, QC, G9A 4J4 > Canada > fmenard@xittel.net > Tel: (819) 374-2556 ext. 268 > Fax: (819) 374-0395 > Cell: (819) 692-1383 > =20 > ________________________________ >=20 > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: 17 mai 2006 15:12 > To: David Meyer; speermint@ietf.org > Subject: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 >=20 >=20 >=20 > We submitted the updated SPEERMINT Peering Architecture draft.=20 > This update includes many of your input from the last IETF meeting.=20 >=20 > Please review and provide input in the mailing list=20 >=20 >=20 > http://www.ietf.org/internet-drafts/draft-khan-ip-serv-peer-ar > ch-02.txt > rch-02.txt> =20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 19 11:31:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh6vy-000785-Ff; Fri, 19 May 2006 11:30:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh6vw-000780-RA for speermint@ietf.org; Fri, 19 May 2006 11:30:32 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh6vu-0007mf-Ci for speermint@ietf.org; Fri, 19 May 2006 11:30:32 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k4JFURbk014112 for ; Fri, 19 May 2006 08:30:27 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k4JFURQv014111 for speermint@ietf.org; Fri, 19 May 2006 08:30:27 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 19 May 2006 08:30:27 -0700 From: David Meyer To: speermint@ietf.org Message-ID: <20060519153027.GA14103@1-4-5.net> Mime-Version: 1.0 User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [Speermint] FYI -- [ietf-secretariat@ietf.org: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada] X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0540719885==" Errors-To: speermint-bounces@ietf.org --===============0540719885== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable ----- Forwarded message from ietf-secretariat@ietf.org ----- > From: ietf-secretariat@ietf.org > To: ietf-announce@ietf.org > Cc:=20 > Subject: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting > in Montreal, Quebec, Canada=20 > Date: Fri, 19 May 2006 00:00:01 -0400 >=20 >=20 > There are two (2) Internet-Draft cutoff dates for the 66th=20 > IETF Meeting in Montreal, Quebec, Canada: >=20 > June 19th: Cutoff Date for Initial (i.e., version -00)=20 > Internet-Draft Submissions=20 >=20 > All initial Internet-Drafts (version -00) must be submitted by Monday,=20 > June 19th at 9:00 AM ET. As always, all initial submissions with a=20 > filename beginning with "draft-ietf" must be approved by the=20 > appropriate WG Chair before they can be processed or announced. The=20 > Secretariat would appreciate receiving WG Chair approval by Monday,=20 > June 12th at 9:00 AM ET. >=20 > June 26th: Cutoff Date for Revised (i.e., version -01 and higher)=20 > Internet-Draft Submissions=20 >=20 > All revised Internet-Drafts (version -01 and higher) must be submitted=20 > by Monday, June 26th at 9:00 AM ET. >=20 > Initial and revised Internet-Drafts received after their respective=20 > cutoff dates will not be made available in the Internet-Drafts=20 > directory or announced until on or after Monday, July 10th at 9:00=20 > AM ET, when Internet-Draft posting resumes. Please do not wait until=20 > the last minute to submit. >=20 > Thank you for your understanding and cooperation. If you have any=20 > questions or concerns, then please send a message to=20 > internet-drafts@ietf.org. >=20 > The IETF Secretariat >=20 > FYI: The Internet-Draft cutoff dates as well as other significant dates > for the 66th IETF Meeting can be found at http://www.ietf.org/meetings/cu= toff_dates_66.html. >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce ----- End forwarded message ----- --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEbeSTORgD1qCZ2KcRAhyeAJ0VcXNFXwJyqDAwjSFZsyOlR3la1gCghZzX eqDFFrnsIUgkqkTogeZxbg0= =8h2c -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH-- --===============0540719885== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0540719885==-- From speermint-bounces@ietf.org Tue May 23 10:54:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiYGr-0001Yy-PG; Tue, 23 May 2006 10:54:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiYGq-0001WT-L8 for speermint@ietf.org; Tue, 23 May 2006 10:54:04 -0400 Received: from outbound-red.frontbridge.com ([216.148.222.49] helo=outbound2-red-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiYGo-0003L4-2r for speermint@ietf.org; Tue, 23 May 2006 10:54:04 -0400 Received: from outbound2-red.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-red-R.bigfish.com (Postfix) with ESMTP id 6A86AB2A97A; Tue, 23 May 2006 14:54:01 +0000 (UTC) Received: from mail58-red-R.bigfish.com (unknown [172.18.12.1]) by outbound2-red.bigfish.com (Postfix) with ESMTP id 5FA14B2A961; Tue, 23 May 2006 14:54:01 +0000 (UTC) Received: from mail58-red.bigfish.com (localhost.localdomain [127.0.0.1]) by mail58-red-R.bigfish.com (Postfix) with ESMTP id 6CF1033D812; Tue, 23 May 2006 14:54:01 +0000 (UTC) X-BigFish: V Received: by mail58-red (MessageSwitch) id 1148396041342712_3045; Tue, 23 May 2006 14:54:01 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail58-red.bigfish.com (Postfix) with ESMTP id 382AD33D211; Tue, 23 May 2006 14:54:01 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k4NErvAg022747; Tue, 23 May 2006 09:53:57 -0500 (CDT) Received: from pdawg04a.ad.sprint.com (PDAWG04A.corp.sprint.com [10.122.2.37]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k4NErpC11851; Tue, 23 May 2006 09:53:51 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by pdawg04a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 May 2006 09:53:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 23 May 2006 09:53:20 -0500 Message-ID: <978886E57CC1D64EAFAC157B98E36F9E08F0CD8F@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLA= From: "Khan, Sohel Q [CTO]" To: "Michael Hammer \(mhammer\)" , "Francois D. Menard" , "David Meyer" , X-OriginalArrivalTime: 23 May 2006 14:53:13.0444 (UTC) FILETIME=[9DC05240:01C67E78] X-Spam-Score: 0.1 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Mike, Do you know the name of the SIP WG draft defining SIP interoperability? = I cannot find it in SIP WG web. Sohel -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Thursday, May 18, 2006 2:08 PM To: Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer; = speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Francois, I understand the reasoning, but any mention of the PSTN tends to raise = red flags. It also seems to duplicate other efforts inside IETF and = out: The SIP WG is trying to compile a document defining interoperability for = SIP. I see that as one form of federation. Such an RFC (when it = appears) could be cited. =20 ATIS is planning an ANSI standard that could also be cited. That may = influence the CRTC. I think all we need is for Speermint to have a mechanisms to identify = such reference points. It's a measure of indirection. I don't think we = need to compile those (dare I say) profiles in Speermint. Mike > -----Original Message----- > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > Sent: Wednesday, May 17, 2006 5:10 PM > To: 'Khan, Sohel Q [CTO]'; 'David Meyer'; speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > I would, because ultimately, the minimum level of interoperability=20 > will be (at least in Canada) mandated by the regulator (here, the=20 > CRTC). So therefore, the baseline comparison is what goes on today in=20 > the SS7 PSTN. >=20 > F. > -- > Fran=E7ois D. M=E9nard > Charg=E9 de projet > Xit t=E9l=E9com inc. > 1350 rue Royale #800 > Trois-Rivi=E8res, QC, G9A 4J4 > Canada > fmenard@xittelecom.com > Tel: (819) 374-2556 ext. 268 > Fax: (819) 374-0395 > Cell: (819) 692-1383 > =20 >=20 > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: 17 mai 2006 16:50 > To: Francois D. Menard; David Meyer; speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > Franois, >=20 > Thanks for the input. Question: is it necessary to mention > SS7 specifically? >=20 >=20 > -----Original Message----- > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > Sent: Wednesday, May 17, 2006 2:37 PM > To: Khan, Sohel Q [CTO]; 'David Meyer'; speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > Just completed reading 02 and I have the following proposal: > =20 > 1) With regards to SIP interoperability in section 4.3, I would like=20 > to mention that in Canada, we have agreed at the CISC NTWG > (http://www.crtc.gc.ca/cisc/eng/cisf3d0.htm) that that the following=20 > RFCs are sufficient to implement the equivalement of the CCS7 minimum=20 > message > set: > =20 > http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTRE035B.doc > =20 > SIP + > http://www.ietf.org/rfc/rfc3323.txt > http://www.ietf.org/rfc/rfc3325.txt > =20 > I therefore propose that we state the following in the document under=20 > SIP interoperability in section 4.3: >=20 > It is expected that the level of SIP interoperability achieved between = > two service providers will arise out of the outcome of market-based=20 > bilateral negociations. >=20 > However, it is expected that a level of interoperability equivalent to = > the > SS7 minimum message set of the conventional PSTN will require service=20 > prociders to implement SF that SHALL BE compliant with both, RFC 3323=20 > (A Privacy Mechanism for the Session Initiation Protocol) and RFC 3325 = > (Private Extensions to the Session Initiation Protocol (SIP) for=20 > Asserted Identity within Trusted Networks). >=20 > -=3DFrancois=3D- > -- > Fran=E7ois D. M=E9nard > Projet manager > Xittel telecommunications inc. > 1350 Royale #800 > Trois-Rivieres, QC, G9A 4J4 > Canada > fmenard@xittel.net > Tel: (819) 374-2556 ext. 268 > Fax: (819) 374-0395 > Cell: (819) 692-1383 > =20 > ________________________________ >=20 > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: 17 mai 2006 15:12 > To: David Meyer; speermint@ietf.org > Subject: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 >=20 >=20 >=20 > We submitted the updated SPEERMINT Peering Architecture draft.=20 > This update includes many of your input from the last IETF meeting.=20 >=20 > Please review and provide input in the mailing list >=20 >=20 > http://www.ietf.org/internet-drafts/draft-khan-ip-serv-peer-ar > ch-02.txt > rch-02.txt> >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 23 11:13:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiYZi-0005v0-4b; Tue, 23 May 2006 11:13:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiYZh-0005uu-Ai for speermint@ietf.org; Tue, 23 May 2006 11:13:33 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiYZe-0003y0-LS for speermint@ietf.org; Tue, 23 May 2006 11:13:33 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 23 May 2006 08:13:28 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,161,1146466800"; d="scan'208"; a="28714461:sNHT24524456" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4NFDRvF001672; Tue, 23 May 2006 11:13:27 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 May 2006 11:13:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 23 May 2006 11:13:26 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3017E624A@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMA== From: "Michael Hammer \(mhammer\)" To: "Khan, Sohel Q [CTO]" , "Francois D. Menard" , "David Meyer" , X-OriginalArrivalTime: 23 May 2006 15:13:27.0194 (UTC) FILETIME=[7133DFA0:01C67E7B] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Sohel, I was suspecting that this would be an off-shoot of Rosenberg's = Hitchiker's Guide. =20 Note that Section 3 is Core SIP specifications. Mike =20 > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com]=20 > Sent: Tuesday, May 23, 2006 10:53 AM > To: Michael Hammer (mhammer); Francois D. Menard; David=20 > Meyer; speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > Mike, >=20 > Do you know the name of the SIP WG draft defining SIP=20 > interoperability? I cannot find it in SIP WG web. >=20 > Sohel >=20 >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Thursday, May 18, 2006 2:08 PM > To: Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer;=20 > speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > Francois, >=20 > I understand the reasoning, but any mention of the PSTN tends=20 > to raise red flags. It also seems to duplicate other efforts=20 > inside IETF and out: >=20 > The SIP WG is trying to compile a document defining=20 > interoperability for SIP. I see that as one form of=20 > federation. Such an RFC (when it appears) could be cited. =20 >=20 > ATIS is planning an ANSI standard that could also be cited. =20 > That may influence the CRTC. >=20 > I think all we need is for Speermint to have a mechanisms to=20 > identify such reference points. It's a measure of=20 > indirection. I don't think we need to compile those (dare I=20 > say) profiles in Speermint. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > > Sent: Wednesday, May 17, 2006 5:10 PM > > To: 'Khan, Sohel Q [CTO]'; 'David Meyer'; speermint@ietf.org > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering=20 > Architecture > >=20 > > I would, because ultimately, the minimum level of interoperability=20 > > will be (at least in Canada) mandated by the regulator (here, the=20 > > CRTC). So therefore, the baseline comparison is what goes=20 > on today in=20 > > the SS7 PSTN. > >=20 > > F. > > -- > > Fran=E7ois D. M=E9nard > > Charg=E9 de projet > > Xit t=E9l=E9com inc. > > 1350 rue Royale #800 > > Trois-Rivi=E8res, QC, G9A 4J4 > > Canada > > fmenard@xittelecom.com > > Tel: (819) 374-2556 ext. 268 > > Fax: (819) 374-0395 > > Cell: (819) 692-1383 > > =20 > >=20 > > -----Original Message----- > > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > Sent: 17 mai 2006 16:50 > > To: Francois D. Menard; David Meyer; speermint@ietf.org > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering=20 > Architecture > >=20 > > Franois, > >=20 > > Thanks for the input. Question: is it necessary to mention > > SS7 specifically? > >=20 > >=20 > > -----Original Message----- > > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > > Sent: Wednesday, May 17, 2006 2:37 PM > > To: Khan, Sohel Q [CTO]; 'David Meyer'; speermint@ietf.org > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering=20 > Architecture > >=20 > > Just completed reading 02 and I have the following proposal: > > =20 > > 1) With regards to SIP interoperability in section 4.3, I=20 > would like=20 > > to mention that in Canada, we have agreed at the CISC NTWG > > (http://www.crtc.gc.ca/cisc/eng/cisf3d0.htm) that that the=20 > following=20 > > RFCs are sufficient to implement the equivalement of the=20 > CCS7 minimum=20 > > message > > set: > > =20 > > http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTRE035B.doc > > =20 > > SIP + > > http://www.ietf.org/rfc/rfc3323.txt > > http://www.ietf.org/rfc/rfc3325.txt > > =20 > > I therefore propose that we state the following in the=20 > document under=20 > > SIP interoperability in section 4.3: > >=20 > > It is expected that the level of SIP interoperability=20 > achieved between=20 > > two service providers will arise out of the outcome of market-based=20 > > bilateral negociations. > >=20 > > However, it is expected that a level of interoperability=20 > equivalent to=20 > > the > > SS7 minimum message set of the conventional PSTN will=20 > require service=20 > > prociders to implement SF that SHALL BE compliant with=20 > both, RFC 3323=20 > > (A Privacy Mechanism for the Session Initiation Protocol)=20 > and RFC 3325=20 > > (Private Extensions to the Session Initiation Protocol (SIP) for=20 > > Asserted Identity within Trusted Networks). > >=20 > > -=3DFrancois=3D- > > -- > > Fran=E7ois D. M=E9nard > > Projet manager > > Xittel telecommunications inc. > > 1350 Royale #800 > > Trois-Rivieres, QC, G9A 4J4 > > Canada > > fmenard@xittel.net > > Tel: (819) 374-2556 ext. 268 > > Fax: (819) 374-0395 > > Cell: (819) 692-1383 > > =20 > > ________________________________ > >=20 > > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > Sent: 17 mai 2006 15:12 > > To: David Meyer; speermint@ietf.org > > Subject: [Speermint] Updated Draft: SPEERMINT Peering Architecture > >=20 > >=20 > >=20 > >=20 > > We submitted the updated SPEERMINT Peering Architecture draft.=20 > > This update includes many of your input from the last IETF meeting.=20 > >=20 > > Please review and provide input in the mailing list > >=20 > >=20 > > http://www.ietf.org/internet-drafts/draft-khan-ip-serv-peer-ar > > ch-02.txt > > > rch-02.txt> > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 23 13:39:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiaqD-0000oy-Jc; Tue, 23 May 2006 13:38:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiaqC-0000iW-8C for speermint@ietf.org; Tue, 23 May 2006 13:38:44 -0400 Received: from [205.151.208.34] (helo=fw.tr.xittelecom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiaqA-0001zj-P6 for speermint@ietf.org; Tue, 23 May 2006 13:38:44 -0400 Received: from [192.168.2.139] (helo=gestionfm) by fw.tr.xittelecom.com with esmtp (Exim 3.36 #1 (Debian)) id 1Ftq7Z-0001AB-00; Fri, 23 Jun 2006 14:11:09 -0400 From: "Francois D. Menard" To: "'Michael Hammer \(mhammer\)'" , "'Khan, Sohel Q [CTO]'" , "'David Meyer'" , Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 23 May 2006 13:38:23 -0400 Message-ID: <013e01c67e8f$b436a120$8b02a8c0@gestionfm> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3017E624A@xmb-rtp-20b.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Sorry to be blunt, But this is precisely what I would like to avoid to do, which is to = depend on ATIS to specify something that could be into an IETF RFC. I still support & defend my proposal amendment. F.=20 -- Fran=E7ois D. M=E9nard Charg=E9 de projet Xit t=E9l=E9com inc. 1350 rue Royale #800 Trois-Rivi=E8res, QC, G9A 4J4 Canada fmenard@xittelecom.com Tel: (819) 374-2556 ext. 268 Fax: (819) 374-0395 Cell: (819) 692-1383 =20 -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: 23 mai 2006 11:13 To: Khan, Sohel Q [CTO]; Francois D. Menard; David Meyer; = speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Sohel, I was suspecting that this would be an off-shoot of Rosenberg's = Hitchiker's Guide. =20 Note that Section 3 is Core SIP specifications. Mike =20 > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: Tuesday, May 23, 2006 10:53 AM > To: Michael Hammer (mhammer); Francois D. Menard; David Meyer;=20 > speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > Mike, >=20 > Do you know the name of the SIP WG draft defining SIP=20 > interoperability? I cannot find it in SIP WG web. >=20 > Sohel >=20 >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Thursday, May 18, 2006 2:08 PM > To: Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer;=20 > speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > Francois, >=20 > I understand the reasoning, but any mention of the PSTN tends to raise = > red flags. It also seems to duplicate other efforts inside IETF and=20 > out: >=20 > The SIP WG is trying to compile a document defining interoperability=20 > for SIP. I see that as one form of federation. Such an RFC (when it=20 > appears) could be cited. >=20 > ATIS is planning an ANSI standard that could also be cited. =20 > That may influence the CRTC. >=20 > I think all we need is for Speermint to have a mechanisms to identify=20 > such reference points. It's a measure of indirection. I don't think=20 > we need to compile those (dare I > say) profiles in Speermint. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > > Sent: Wednesday, May 17, 2006 5:10 PM > > To: 'Khan, Sohel Q [CTO]'; 'David Meyer'; speermint@ietf.org > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > >=20 > > I would, because ultimately, the minimum level of interoperability=20 > > will be (at least in Canada) mandated by the regulator (here, the=20 > > CRTC). So therefore, the baseline comparison is what goes > on today in > > the SS7 PSTN. > >=20 > > F. > > -- > > Fran=E7ois D. M=E9nard > > Charg=E9 de projet > > Xit t=E9l=E9com inc. > > 1350 rue Royale #800 > > Trois-Rivi=E8res, QC, G9A 4J4 > > Canada > > fmenard@xittelecom.com > > Tel: (819) 374-2556 ext. 268 > > Fax: (819) 374-0395 > > Cell: (819) 692-1383 > > =20 > >=20 > > -----Original Message----- > > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > Sent: 17 mai 2006 16:50 > > To: Francois D. Menard; David Meyer; speermint@ietf.org > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > >=20 > > Franois, > >=20 > > Thanks for the input. Question: is it necessary to mention > > SS7 specifically? > >=20 > >=20 > > -----Original Message----- > > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > > Sent: Wednesday, May 17, 2006 2:37 PM > > To: Khan, Sohel Q [CTO]; 'David Meyer'; speermint@ietf.org > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > >=20 > > Just completed reading 02 and I have the following proposal: > > =20 > > 1) With regards to SIP interoperability in section 4.3, I > would like > > to mention that in Canada, we have agreed at the CISC NTWG > > (http://www.crtc.gc.ca/cisc/eng/cisf3d0.htm) that that the > following > > RFCs are sufficient to implement the equivalement of the > CCS7 minimum > > message > > set: > > =20 > > http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTRE035B.doc > > =20 > > SIP + > > http://www.ietf.org/rfc/rfc3323.txt > > http://www.ietf.org/rfc/rfc3325.txt > > =20 > > I therefore propose that we state the following in the > document under > > SIP interoperability in section 4.3: > >=20 > > It is expected that the level of SIP interoperability > achieved between > > two service providers will arise out of the outcome of market-based=20 > > bilateral negociations. > >=20 > > However, it is expected that a level of interoperability > equivalent to > > the > > SS7 minimum message set of the conventional PSTN will > require service > > prociders to implement SF that SHALL BE compliant with > both, RFC 3323 > > (A Privacy Mechanism for the Session Initiation Protocol) > and RFC 3325 > > (Private Extensions to the Session Initiation Protocol (SIP) for=20 > > Asserted Identity within Trusted Networks). > >=20 > > -=3DFrancois=3D- > > -- > > Fran=E7ois D. M=E9nard > > Projet manager > > Xittel telecommunications inc. > > 1350 Royale #800 > > Trois-Rivieres, QC, G9A 4J4 > > Canada > > fmenard@xittel.net > > Tel: (819) 374-2556 ext. 268 > > Fax: (819) 374-0395 > > Cell: (819) 692-1383 > > =20 > > ________________________________ > >=20 > > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > Sent: 17 mai 2006 15:12 > > To: David Meyer; speermint@ietf.org > > Subject: [Speermint] Updated Draft: SPEERMINT Peering Architecture > >=20 > >=20 > >=20 > >=20 > > We submitted the updated SPEERMINT Peering Architecture draft.=20 > > This update includes many of your input from the last IETF meeting.=20 > >=20 > > Please review and provide input in the mailing list > >=20 > >=20 > > http://www.ietf.org/internet-drafts/draft-khan-ip-serv-peer-ar > > ch-02.txt > > > rch-02.txt> > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 23 14:13:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FibNr-0003Po-I8; Tue, 23 May 2006 14:13:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FibNq-0003Pj-Ne for speermint@ietf.org; Tue, 23 May 2006 14:13:30 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FibNp-0003Pn-9U for speermint@ietf.org; Tue, 23 May 2006 14:13:30 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 23 May 2006 11:13:29 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,161,1146466800"; d="scan'208"; a="28734768:sNHT26520852" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4NIDSTL023276; Tue, 23 May 2006 14:13:28 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 May 2006 14:13:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 23 May 2006 14:13:26 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3017E6341@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacA= From: "Michael Hammer \(mhammer\)" To: "Francois D. Menard" , "Khan, Sohel Q [CTO]" , "David Meyer" , X-OriginalArrivalTime: 23 May 2006 18:13:27.0996 (UTC) FILETIME=[96FB77C0:01C67E94] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I don't see anything diametrically opposed between what I suggested and = what you are suggesting. =20 I did not say this needs to be SIP WG or ATIS or IPSphere or any = particular group's SIP profile. =20 I am suggesting is that we don't need yet another group to create a new = SIP RFC list. I am suggesting that to make Speermint work more generally useful, it = should provide a pointer mechanism to any such group's work as your = hearts desire, depending on what federation you pray to. If there is to be an IETF-approved SIP profile, I think it should first = be decided if that is the turf of the Speermint or the SIP WG. Those last two statements are at the heart of my concerns. Mike > -----Original Message----- > From: Francois D. Menard [mailto:fmenard@xittelecom.com]=20 > Sent: Tuesday, May 23, 2006 1:38 PM > To: Michael Hammer (mhammer); 'Khan, Sohel Q [CTO]'; 'David=20 > Meyer'; speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > Sorry to be blunt, >=20 > But this is precisely what I would like to avoid to do, which=20 > is to depend on ATIS to specify something that could be into=20 > an IETF RFC. >=20 > I still support & defend my proposal amendment. >=20 > F.=20 >=20 >=20 > -- > Fran=E7ois D. M=E9nard > Charg=E9 de projet > Xit t=E9l=E9com inc. > 1350 rue Royale #800 > Trois-Rivi=E8res, QC, G9A 4J4 > Canada > fmenard@xittelecom.com > Tel: (819) 374-2556 ext. 268 > Fax: (819) 374-0395 > Cell: (819) 692-1383 > =20 >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: 23 mai 2006 11:13 > To: Khan, Sohel Q [CTO]; Francois D. Menard; David Meyer;=20 > speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > Sohel, >=20 > I was suspecting that this would be an off-shoot of=20 > Rosenberg's Hitchiker's Guide. =20 >=20 > Note that Section 3 is Core SIP specifications. >=20 > Mike > =20 >=20 > > -----Original Message----- > > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > Sent: Tuesday, May 23, 2006 10:53 AM > > To: Michael Hammer (mhammer); Francois D. Menard; David Meyer;=20 > > speermint@ietf.org > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering=20 > Architecture > >=20 > > Mike, > >=20 > > Do you know the name of the SIP WG draft defining SIP=20 > > interoperability? I cannot find it in SIP WG web. > >=20 > > Sohel > >=20 > >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Thursday, May 18, 2006 2:08 PM > > To: Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer;=20 > > speermint@ietf.org > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering=20 > Architecture > >=20 > > Francois, > >=20 > > I understand the reasoning, but any mention of the PSTN=20 > tends to raise=20 > > red flags. It also seems to duplicate other efforts inside IETF and > > out: > >=20 > > The SIP WG is trying to compile a document defining=20 > interoperability=20 > > for SIP. I see that as one form of federation. Such an=20 > RFC (when it > > appears) could be cited. > >=20 > > ATIS is planning an ANSI standard that could also be cited. =20 > > That may influence the CRTC. > >=20 > > I think all we need is for Speermint to have a mechanisms=20 > to identify=20 > > such reference points. It's a measure of indirection. I=20 > don't think=20 > > we need to compile those (dare I > > say) profiles in Speermint. > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > > > Sent: Wednesday, May 17, 2006 5:10 PM > > > To: 'Khan, Sohel Q [CTO]'; 'David Meyer'; speermint@ietf.org > > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering > > Architecture > > >=20 > > > I would, because ultimately, the minimum level of=20 > interoperability=20 > > > will be (at least in Canada) mandated by the regulator (here, the=20 > > > CRTC). So therefore, the baseline comparison is what goes > > on today in > > > the SS7 PSTN. > > >=20 > > > F. > > > -- > > > Fran=E7ois D. M=E9nard > > > Charg=E9 de projet > > > Xit t=E9l=E9com inc. > > > 1350 rue Royale #800 > > > Trois-Rivi=E8res, QC, G9A 4J4 > > > Canada > > > fmenard@xittelecom.com > > > Tel: (819) 374-2556 ext. 268 > > > Fax: (819) 374-0395 > > > Cell: (819) 692-1383 > > > =20 > > >=20 > > > -----Original Message----- > > > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > > Sent: 17 mai 2006 16:50 > > > To: Francois D. Menard; David Meyer; speermint@ietf.org > > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering > > Architecture > > >=20 > > > Franois, > > >=20 > > > Thanks for the input. Question: is it necessary to mention > > > SS7 specifically? > > >=20 > > >=20 > > > -----Original Message----- > > > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > > > Sent: Wednesday, May 17, 2006 2:37 PM > > > To: Khan, Sohel Q [CTO]; 'David Meyer'; speermint@ietf.org > > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering > > Architecture > > >=20 > > > Just completed reading 02 and I have the following proposal: > > > =20 > > > 1) With regards to SIP interoperability in section 4.3, I > > would like > > > to mention that in Canada, we have agreed at the CISC NTWG > > > (http://www.crtc.gc.ca/cisc/eng/cisf3d0.htm) that that the > > following > > > RFCs are sufficient to implement the equivalement of the > > CCS7 minimum > > > message > > > set: > > > =20 > > > http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTRE035B.doc > > > =20 > > > SIP + > > > http://www.ietf.org/rfc/rfc3323.txt > > > http://www.ietf.org/rfc/rfc3325.txt > > > =20 > > > I therefore propose that we state the following in the > > document under > > > SIP interoperability in section 4.3: > > >=20 > > > It is expected that the level of SIP interoperability > > achieved between > > > two service providers will arise out of the outcome of=20 > market-based=20 > > > bilateral negociations. > > >=20 > > > However, it is expected that a level of interoperability > > equivalent to > > > the > > > SS7 minimum message set of the conventional PSTN will > > require service > > > prociders to implement SF that SHALL BE compliant with > > both, RFC 3323 > > > (A Privacy Mechanism for the Session Initiation Protocol) > > and RFC 3325 > > > (Private Extensions to the Session Initiation Protocol (SIP) for=20 > > > Asserted Identity within Trusted Networks). > > >=20 > > > -=3DFrancois=3D- > > > -- > > > Fran=E7ois D. M=E9nard > > > Projet manager > > > Xittel telecommunications inc. > > > 1350 Royale #800 > > > Trois-Rivieres, QC, G9A 4J4 > > > Canada > > > fmenard@xittel.net > > > Tel: (819) 374-2556 ext. 268 > > > Fax: (819) 374-0395 > > > Cell: (819) 692-1383 > > > =20 > > > ________________________________ > > >=20 > > > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > > Sent: 17 mai 2006 15:12 > > > To: David Meyer; speermint@ietf.org > > > Subject: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > >=20 > > >=20 > > >=20 > > >=20 > > > We submitted the updated SPEERMINT Peering Architecture draft.=20 > > > This update includes many of your input from the last=20 > IETF meeting.=20 > > >=20 > > > Please review and provide input in the mailing list > > >=20 > > >=20 > > > http://www.ietf.org/internet-drafts/draft-khan-ip-serv-peer-ar > > > ch-02.txt > > > > > rch-02.txt> > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > >=20 > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 23 14:50:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fibwp-0008Cq-Se; Tue, 23 May 2006 14:49:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fibwp-0008Cl-Ip for speermint@ietf.org; Tue, 23 May 2006 14:49:39 -0400 Received: from [205.151.208.34] (helo=fw.tr.xittelecom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fibwo-00054E-BQ for speermint@ietf.org; Tue, 23 May 2006 14:49:39 -0400 Received: from [192.168.2.139] (helo=gestionfm) by fw.tr.xittelecom.com with esmtp (Exim 3.36 #1 (Debian)) id 1FtrES-0001Dw-00; Fri, 23 Jun 2006 15:22:20 -0400 From: "Francois D. Menard" To: "'Michael Hammer \(mhammer\)'" , "'Khan, Sohel Q [CTO]'" , "'David Meyer'" , Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 23 May 2006 14:49:34 -0400 Message-ID: <017201c67e99$a5af6830$8b02a8c0@gestionfm> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3017E6341@xmb-rtp-20b.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > I don't see anything diametrically opposed between what I suggested and what you are suggesting. I would be satisfied with this: SPEERMINT compliance requires replication of the functionality available in the SS7 minumum message set which can be done by SIP, 3323, 3325. Better than SS7 mms functionlality made possible with ATIS, IP Sphere or other sip profiles will also be considered as SPEERMIT compliant. > If there is to be an IETF-approved SIP profile, I think it should first be decided if that is the turf of the Speermint or the SIP WG. Those last two statements are at the heart of my concerns. SPEERMINT will be completely toothless as an RFC if it just states, compliance with SPEERMINT can be achieved by compliance with non-IETF standards. F. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 23 15:05:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FicBb-00057n-0s; Tue, 23 May 2006 15:04:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FicBZ-00056s-GK for speermint@ietf.org; Tue, 23 May 2006 15:04:53 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FicBY-0005Un-65 for speermint@ietf.org; Tue, 23 May 2006 15:04:53 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FicBA-0000Uj-RQ; Tue, 23 May 2006 14:04:29 -0500 From: "Brian Rosen" To: "'Francois D. Menard'" , "'Michael Hammer \(mhammer\)'" , "'Khan, Sohel Q [CTO]'" , "'David Meyer'" , Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 23 May 2006 15:04:31 -0400 Message-ID: <09d001c67e9b$bb2850d0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSsw In-Reply-To: <017201c67e99$a5af6830$8b02a8c0@gestionfm> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org By far the largest mistake EVER made by the IETF in the development of SIP was to allow SIP to be extended to imitate the existing PSTN. If we ever were to start again, the golden rule would be DON'T IMITATE THE PSTN, and the corollary would be "Just because the PSTN does it that way DOES NOT MEAN it's a good idea". So, the very idea that "replication of functionality in the SS7 minimum message set" is the definition of what we need to do makes me want to puke. No, and a pox on your houses for even thinking that. While we're going to start with "basic call", we need to define those call features that must cross domain boundaries. Most of them have existing SIP messaging (in sip-examples, for instance). We need to make sure those features work across the boundary. That has nothing whatsoever to do with an SS7 message. The mms might give us clues on what features might be interesting to put on our list, but I'll bet we end up with a lot less of them, and a bunch of stuff not in SS7 (or C7); inter-domain presence, for example. Brian -----Original Message----- From: Francois D. Menard [mailto:fmenard@xittelecom.com] Sent: Tuesday, May 23, 2006 2:50 PM To: 'Michael Hammer (mhammer)'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > I don't see anything diametrically opposed between what I suggested and what you are suggesting. I would be satisfied with this: SPEERMINT compliance requires replication of the functionality available in the SS7 minumum message set which can be done by SIP, 3323, 3325. Better than SS7 mms functionlality made possible with ATIS, IP Sphere or other sip profiles will also be considered as SPEERMIT compliant. > If there is to be an IETF-approved SIP profile, I think it should first be decided if that is the turf of the Speermint or the SIP WG. Those last two statements are at the heart of my concerns. SPEERMINT will be completely toothless as an RFC if it just states, compliance with SPEERMINT can be achieved by compliance with non-IETF standards. F. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 23 15:27:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FicXL-0004aX-U2; Tue, 23 May 2006 15:27:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FicXK-0004aS-OY for speermint@ietf.org; Tue, 23 May 2006 15:27:22 -0400 Received: from [205.151.208.34] (helo=fw.tr.xittelecom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FicXJ-0006YX-E1 for speermint@ietf.org; Tue, 23 May 2006 15:27:22 -0400 Received: from [192.168.2.139] (helo=gestionfm) by fw.tr.xittelecom.com with esmtp (Exim 3.36 #1 (Debian)) id 1FtroO-0001FV-00; Fri, 23 Jun 2006 15:59:28 -0400 From: "Francois D. Menard" To: "'Brian Rosen'" , "'Michael Hammer \(mhammer\)'" , "'Khan, Sohel Q [CTO]'" , "'David Meyer'" , Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 23 May 2006 15:26:42 -0400 Message-ID: <019401c67e9e$d5da8bc0$8b02a8c0@gestionfm> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAACtFaA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <09d001c67e9b$bb2850d0$640fa8c0@cis.neustar.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian Rosen wrote: > Most of them have existing SIP messaging (in sip-examples, for instance). I agree > We need to make sure those features work across the boundary. I agree > That has nothing whatsoever to do with an SS7 message. I said that the methods embodied in the SS7 minimum message set were recognized in Canada as being implementable in SIP with basis SIP, RFC 3323 and RFC3325. > The mms might give us clues on what features might be interesting to put on our list, but I'll bet we end up with a lot less of them, and a bunch of stuff not in SS7 (or C7); inter-domain presence, for example. That's fine. I just want the standard to state that the minimal SPEERMINT compliant implementation will require compliance with basic SIP, 3323 and 3325. F. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 23 16:32:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FidYB-0002Af-00; Tue, 23 May 2006 16:32:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FidY9-0002AV-T1 for speermint@ietf.org; Tue, 23 May 2006 16:32:17 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FidY8-0002V8-Ca for speermint@ietf.org; Tue, 23 May 2006 16:32:17 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 23 May 2006 13:32:15 -0700 X-IronPort-AV: i="4.05,161,1146466800"; d="scan'208"; a="1811494560:sNHT30481458" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k4NKWFwR007277; Tue, 23 May 2006 13:32:15 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4NKWCsN002844; Tue, 23 May 2006 13:32:15 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 May 2006 16:32:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 23 May 2006 16:32:13 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3017E63F0@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuA= From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , "Francois D. Menard" , "Khan, Sohel Q [CTO]" , "David Meyer" , X-OriginalArrivalTime: 23 May 2006 20:32:14.0651 (UTC) FILETIME=[FA0E30B0:01C67EA7] DKIM-Signature: a=rsa-sha1; q=dns; l=3859; t=1148416335; x=1149280335; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Updated=20Draft=3A=20SPEERMINT=20Peering=20Archite cture; X=v=3Dcisco.com=3B=20h=3DJEBiKFA1nAWjuMdMPpxwPZYTZkA=3D; b=isF6YFwHVkvVIvPBkShL5FPcEXUNpcg3chIzdqx48xD+2nnzWpSg/BA1Pjc7pBHaMP4oQ4lp o5zSBT2o5/9mw3iGjnr1EmgzR1vTXNNucEsqxwc/lNpx36fIXg+iJ5dA; Authentication-Results: sj-dkim-7.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian, I think the the interworking of SIP to PSTN is out of scope here. The issue is whether two peers, once they have discovered each other, can know what subset of SIP they need to support. I don't think there is any need to go down the rabbit hole on what applications are supported and whether they are PSTN emulations or simulations or whatever. We may know in the back of our mind that some application won't work if RFC X is not supported, but we don't need to discuss that. We need only to focus on what SIP RFCs are needed on the SIP peer interface. While coloring within those lines, the next question is whether there is a single subset that can be defined or whether there will be many. I am betting on many, probably a different set for each federation or even bilateral pairing that might exist. That could be another rabbit hole. I would be happy if two peers could point to the same subset and agree to use it, no matter how many subsets might exist. Mike > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, May 23, 2006 3:05 PM > To: 'Francois D. Menard'; Michael Hammer (mhammer); 'Khan,=20 > Sohel Q [CTO]'; 'David Meyer'; speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > By far the largest mistake EVER made by the IETF in the=20 > development of SIP was to allow SIP to be extended to imitate=20 > the existing PSTN. If we ever were to start again, the=20 > golden rule would be DON'T IMITATE THE PSTN, and the=20 > corollary would be "Just because the PSTN does it that way=20 > DOES NOT MEAN it's a good idea". >=20 > So, the very idea that "replication of functionality in the=20 > SS7 minimum message set" is the definition of what we need to=20 > do makes me want to puke. >=20 > No, and a pox on your houses for even thinking that. >=20 > While we're going to start with "basic call", we need to=20 > define those call features that must cross domain boundaries.=20 > Most of them have existing SIP messaging (in sip-examples,=20 > for instance). We need to make sure those features work=20 > across the boundary. That has nothing whatsoever to do with=20 > an SS7 message. The mms might give us clues on what features=20 > might be interesting to put on our list, but I'll bet we end=20 > up with a lot less of them, and a bunch of stuff not in SS7=20 > (or C7); inter-domain presence, for example. >=20 > Brian >=20 > -----Original Message----- > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > Sent: Tuesday, May 23, 2006 2:50 PM > To: 'Michael Hammer (mhammer)'; 'Khan, Sohel Q [CTO]'; 'David=20 > Meyer'; speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > > I don't see anything diametrically opposed between what I suggested=20 > > and > what you are suggesting. =20 >=20 > I would be satisfied with this: >=20 > SPEERMINT compliance requires replication of the=20 > functionality available in the SS7 minumum message set which=20 > can be done by SIP, 3323, 3325. Better than SS7 mms=20 > functionlality made possible with ATIS, IP Sphere or other=20 > sip profiles will also be considered as SPEERMIT compliant. >=20 > > If there is to be an IETF-approved SIP profile, I think it should=20 > > first be > decided if that is the turf of the Speermint or the SIP WG. > Those last two statements are at the heart of my concerns. >=20 > SPEERMINT will be completely toothless as an RFC if it just=20 > states, compliance with SPEERMINT can be achieved by=20 > compliance with non-IETF standards. >=20 > F. >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 23 16:42:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FidhL-0005JE-0u; Tue, 23 May 2006 16:41:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FidhJ-0005G4-Jz for speermint@ietf.org; Tue, 23 May 2006 16:41:45 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FidhI-0002ws-EH for speermint@ietf.org; Tue, 23 May 2006 16:41:45 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Tue, 23 May 2006 16:42:13 -0400 id 01588126.447373A5.000040EB Message-ID: <4473737E.5090101@hxr.us> Date: Tue, 23 May 2006 16:41:34 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture References: <09d001c67e9b$bb2850d0$640fa8c0@cis.neustar.com> In-Reply-To: <09d001c67e9b$bb2850d0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: speermint@ietf.org, "'Khan, Sohel Q \[CTO\]'" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian Rosen wrote: > By far the largest mistake EVER made by the IETF in the development of SIP > was to allow SIP to be extended to imitate the existing PSTN. If we ever > were to start again, the golden rule would be DON'T IMITATE THE PSTN, and > the corollary would be "Just because the PSTN does it that way DOES NOT MEAN > it's a good idea". > > So, the very idea that "replication of functionality in the SS7 minimum > message set" is the definition of what we need to do makes me want to puke. I agree totally with Brian. We should not try to replicate the PSTN over IP. > No, and a pox on your houses for even thinking that. If that's what it takes... :) -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 23 16:50:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FidpV-0000va-8I; Tue, 23 May 2006 16:50:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FidpU-0000vN-JS for speermint@ietf.org; Tue, 23 May 2006 16:50:12 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FidpS-0003AF-VY for speermint@ietf.org; Tue, 23 May 2006 16:50:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 23 May 2006 22:54:07 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A61@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAANiSfA== From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" , "Brian Rosen" , "Francois D. Menard" , "Khan, Sohel Q [CTO]" , "David Meyer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org >I think the the interworking of SIP to PSTN is out of scope here. Yes I did not find anything about this in the charter. It is not even mentioned in the out-of-scope section (which mentions at=20 least H.323 ;-) =20 >While coloring within those lines, the next question is whether there = is >a single subset that can be defined or whether there will be many. I = am >betting on many, probably a different set for each federation or even >bilateral pairing that might exist.=20 =20 I always had the idea that we could define minimum requrements (which could be the overlap of the many subsets) but maybe I am asking too much Or is SIP already as baroque at OSI FTAM was? (where we could only find bilateral "peerings" between DEC, IBM and Siemens, but not a subset with worked with all three ;-) Richard =20 ________________________________ Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Gesendet: Di 23.05.2006 22:32 An: Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer; = speermint@ietf.org Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Brian, I think the the interworking of SIP to PSTN is out of scope here. The issue is whether two peers, once they have discovered each other, can know what subset of SIP they need to support. I don't think there is any need to go down the rabbit hole on what applications are supported and whether they are PSTN emulations or simulations or whatever. We may know in the back of our mind that some application won't work if RFC X is not supported, but we don't need to discuss that. We need only to focus on what SIP RFCs are needed on the SIP peer interface. While coloring within those lines, the next question is whether there is a single subset that can be defined or whether there will be many. I am betting on many, probably a different set for each federation or even bilateral pairing that might exist. That could be another rabbit hole. I would be happy if two peers could point to the same subset and agree to use it, no matter how many subsets might exist. Mike > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, May 23, 2006 3:05 PM > To: 'Francois D. Menard'; Michael Hammer (mhammer); 'Khan, > Sohel Q [CTO]'; 'David Meyer'; speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > By far the largest mistake EVER made by the IETF in the > development of SIP was to allow SIP to be extended to imitate > the existing PSTN. If we ever were to start again, the > golden rule would be DON'T IMITATE THE PSTN, and the > corollary would be "Just because the PSTN does it that way > DOES NOT MEAN it's a good idea". > > So, the very idea that "replication of functionality in the > SS7 minimum message set" is the definition of what we need to > do makes me want to puke. > > No, and a pox on your houses for even thinking that. > > While we're going to start with "basic call", we need to > define those call features that must cross domain boundaries. > Most of them have existing SIP messaging (in sip-examples, > for instance). We need to make sure those features work > across the boundary. That has nothing whatsoever to do with > an SS7 message. The mms might give us clues on what features > might be interesting to put on our list, but I'll bet we end > up with a lot less of them, and a bunch of stuff not in SS7 > (or C7); inter-domain presence, for example. > > Brian > > -----Original Message----- > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > Sent: Tuesday, May 23, 2006 2:50 PM > To: 'Michael Hammer (mhammer)'; 'Khan, Sohel Q [CTO]'; 'David > Meyer'; speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > I don't see anything diametrically opposed between what I suggested > > and > what you are suggesting.=20 > > I would be satisfied with this: > > SPEERMINT compliance requires replication of the > functionality available in the SS7 minumum message set which > can be done by SIP, 3323, 3325. Better than SS7 mms > functionlality made possible with ATIS, IP Sphere or other > sip profiles will also be considered as SPEERMIT compliant. > > > If there is to be an IETF-approved SIP profile, I think it should > > first be > decided if that is the turf of the Speermint or the SIP WG. > Those last two statements are at the heart of my concerns. > > SPEERMINT will be completely toothless as an RFC if it just > states, compliance with SPEERMINT can be achieved by > compliance with non-IETF standards. > > F. > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 23 16:50:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FidpN-0000um-0Q; Tue, 23 May 2006 16:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FidpM-0000uh-Do for speermint@ietf.org; Tue, 23 May 2006 16:50:04 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FidpL-0003AB-0Y for speermint@ietf.org; Tue, 23 May 2006 16:50:04 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Fidoq-0007mQ-7v; Tue, 23 May 2006 15:49:33 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Francois D. Menard'" , "'Khan, Sohel Q [CTO]'" , "'David Meyer'" , Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 23 May 2006 16:49:35 -0400 Message-ID: <0a5001c67eaa$695424a0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAAKguMA== In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3017E63F0@xmb-rtp-20b.amer.cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I mostly agree, but you have to decide what is in the set of RFCs, and to me, that is what call features are supported. So, I don't want to see an argument that says "we have to implement RFC xxxx because I like the author". I want to say "because we agree such and such feature works across the peering point, we must implement RFCs x, y and z". Dunno whether we need more than one list. Try for one and see what happens, back off if you can't get consensus. Brian -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Tuesday, May 23, 2006 4:32 PM To: Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Brian, I think the the interworking of SIP to PSTN is out of scope here. The issue is whether two peers, once they have discovered each other, can know what subset of SIP they need to support. I don't think there is any need to go down the rabbit hole on what applications are supported and whether they are PSTN emulations or simulations or whatever. We may know in the back of our mind that some application won't work if RFC X is not supported, but we don't need to discuss that. We need only to focus on what SIP RFCs are needed on the SIP peer interface. While coloring within those lines, the next question is whether there is a single subset that can be defined or whether there will be many. I am betting on many, probably a different set for each federation or even bilateral pairing that might exist. That could be another rabbit hole. I would be happy if two peers could point to the same subset and agree to use it, no matter how many subsets might exist. Mike > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, May 23, 2006 3:05 PM > To: 'Francois D. Menard'; Michael Hammer (mhammer); 'Khan, > Sohel Q [CTO]'; 'David Meyer'; speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > By far the largest mistake EVER made by the IETF in the > development of SIP was to allow SIP to be extended to imitate > the existing PSTN. If we ever were to start again, the > golden rule would be DON'T IMITATE THE PSTN, and the > corollary would be "Just because the PSTN does it that way > DOES NOT MEAN it's a good idea". > > So, the very idea that "replication of functionality in the > SS7 minimum message set" is the definition of what we need to > do makes me want to puke. > > No, and a pox on your houses for even thinking that. > > While we're going to start with "basic call", we need to > define those call features that must cross domain boundaries. > Most of them have existing SIP messaging (in sip-examples, > for instance). We need to make sure those features work > across the boundary. That has nothing whatsoever to do with > an SS7 message. The mms might give us clues on what features > might be interesting to put on our list, but I'll bet we end > up with a lot less of them, and a bunch of stuff not in SS7 > (or C7); inter-domain presence, for example. > > Brian > > -----Original Message----- > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > Sent: Tuesday, May 23, 2006 2:50 PM > To: 'Michael Hammer (mhammer)'; 'Khan, Sohel Q [CTO]'; 'David > Meyer'; speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > I don't see anything diametrically opposed between what I suggested > > and > what you are suggesting. > > I would be satisfied with this: > > SPEERMINT compliance requires replication of the > functionality available in the SS7 minumum message set which > can be done by SIP, 3323, 3325. Better than SS7 mms > functionlality made possible with ATIS, IP Sphere or other > sip profiles will also be considered as SPEERMIT compliant. > > > If there is to be an IETF-approved SIP profile, I think it should > > first be > decided if that is the turf of the Speermint or the SIP WG. > Those last two statements are at the heart of my concerns. > > SPEERMINT will be completely toothless as an RFC if it just > states, compliance with SPEERMINT can be achieved by > compliance with non-IETF standards. > > F. > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 23 16:59:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FidyL-0003x2-VI; Tue, 23 May 2006 16:59:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FidyK-0003wg-JS for speermint@ietf.org; Tue, 23 May 2006 16:59:20 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FidyJ-0003S5-A8 for speermint@ietf.org; Tue, 23 May 2006 16:59:20 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id AEAE51A39F; Tue, 23 May 2006 22:59:10 +0200 (CEST) Date: Tue, 23 May 2006 22:59:10 +0200 From: Otmar Lendl To: "Michael Hammer (mhammer)" Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Message-ID: <20060523205910.GB1811@nic.at> Mail-Followup-To: Otmar Lendl , "Michael Hammer (mhammer)" , Brian Rosen , "Francois D. Menard" , "Khan, Sohel Q [CTO]" , David Meyer , speermint@ietf.org References: <072C5B76F7CEAB488172C6F64B30B5E3017E63F0@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3017E63F0@xmb-rtp-20b.amer.cisco.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: speermint@ietf.org, "Khan, Sohel Q \[CTO\]" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/05/23 22:05, "Michael Hammer (mhammer)" wrote: > > I think the the interworking of SIP to PSTN is out of scope here. The > issue is whether two peers, once they have discovered each other, can > know what subset of SIP they need to support. [...] > While coloring within those lines, the next question is whether there is > a single subset that can be defined or whether there will be many. I am > betting on many, probably a different set for each federation or even > bilateral pairing that might exist. That could be another rabbit hole. > I would be happy if two peers could point to the same subset and agree > to use it, no matter how many subsets might exist. Well, I've got a draft to sell to you. >From the example section of draft-lendl-domain-policy-ddds-00.txt: o If the carrier example.com only accepts SIP calls (in addition to PSTN interconnect) if the PSTN emulation is good, he might publish a policy like this: $ORIGIN example.com. ; order pref flags service regexp replacement IN NAPTR 10 10 "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:3578!" . IN NAPTR 10 11 "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:3666!" . IN NAPTR 10 12 "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:3960!" . /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 23 17:05:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fie3e-0005im-HY; Tue, 23 May 2006 17:04:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fie3d-0005ib-HG for speermint@ietf.org; Tue, 23 May 2006 17:04:49 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fie3a-0003fy-3J for speermint@ietf.org; Tue, 23 May 2006 17:04:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 May 2006 23:08:51 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A62@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SPEERMINT Peering Architecture - LF - OF - SF Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAATumxg== From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" , "Brian Rosen" , "Francois D. Menard" , "Khan, Sohel Q [CTO]" , "David Meyer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Subject: [Speermint] SPEERMINT Peering Architecture - LF - OF - SF X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Folks, =20 One general statement in advance: Coming from the VON Europe last week with discussions about walled garden and IMS, my overall expression is that this draft in IMS in text-mode. =20 I have another question for clarification to this draft, because I am confused: =20 I do not understand that the LF is discovering the OF o Location Function (LF): Purpose is to enable discovery of the OF=20 peering point.=20 o Operation Function (OF): Purpose is to enable discovery and=20 exchange of policy and parameters to be used in with the SF=20 peering point.=20 o Signaling Function (SF): Purpose is to enable the discovery of=20 endpoints and assist in discovery and exchange of parameters to be = used with the MF peering point.=20 I always had the naive idea (also triggered by the SPEERMINT chartert=20 that e.g. ENUM is a LF and discovering the SIP URIs uses in the SF How is now OF coming in between thsi, especially what is listed in the draft, especially CALEA, Accounting and Applications? "Operational data mediation: TBD=20 o CALEA implementation: TBD=20 o Accounting: Call Detail Record's (CDR's) MAY be collected to be=20 utilized by the peering operators. Based on the application, the=20 format should be an open standard for common consumption of=20 billing systems. Operators may use this data for a number of=20 reasons, including billing in the event the peering relationship=20 becomes asymmetric (unbalanced traffic flow) or there is a Tier 1=20 to Tier 2 relationship. In order to limit the potential for=20 billing systems to impact the OF, a separate server should be=20 created to maintain all records collected from a single=20 interconnection to any number of OF's.=20 An OF can also be a special function that contains bi-laterally=20 disclosed information about the application servers and databases of=20 each IP service provider. An example of this function is to allow a=20 session to select a better suited application server from a set of=20 application servers located inside both service providers' network. = " =20 Richard _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 23 19:55:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Figi9-0001gd-1G; Tue, 23 May 2006 19:54:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Figi7-0001WT-3A for speermint@ietf.org; Tue, 23 May 2006 19:54:47 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Figi5-0003KM-MJ for speermint@ietf.org; Tue, 23 May 2006 19:54:47 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 23 May 2006 16:54:45 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,162,1146466800"; d="scan'208"; a="28765578:sNHT24990792" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4NNsivF026657; Tue, 23 May 2006 19:54:44 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 May 2006 19:54:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 23 May 2006 19:54:42 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3017E6491@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAAKguMAAGwZxw From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , "Francois D. Menard" , "Khan, Sohel Q [CTO]" , "David Meyer" , X-OriginalArrivalTime: 23 May 2006 23:54:44.0588 (UTC) FILETIME=[43FB72C0:01C67EC4] X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org It still seems a slippery slope to me, but if someone can present such a list, great. Mike =20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, May 23, 2006 4:50 PM > To: Michael Hammer (mhammer); 'Francois D. Menard'; 'Khan,=20 > Sohel Q [CTO]'; 'David Meyer'; speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > I mostly agree, but you have to decide what is in the set of=20 > RFCs, and to me, that is what call features are supported. =20 > So, I don't want to see an argument that says "we have to=20 > implement RFC xxxx because I like the author". I want to say=20 > "because we agree such and such feature works across the=20 > peering point, we must implement RFCs x, y and z". >=20 > Dunno whether we need more than one list. Try for one and=20 > see what happens, back off if you can't get consensus. >=20 > Brian >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Tuesday, May 23, 2006 4:32 PM > To: Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO];=20 > David Meyer; speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > Brian, >=20 > I think the the interworking of SIP to PSTN is out of scope=20 > here. The issue is whether two peers, once they have=20 > discovered each other, can know what subset of SIP they need=20 > to support. I don't think there is any need to go down the=20 > rabbit hole on what applications are supported and whether=20 > they are PSTN emulations or simulations or whatever. We may=20 > know in the back of our mind that some application won't work=20 > if RFC X is not supported, but we don't need to discuss that.=20 > We need only to focus on what SIP RFCs are needed on the SIP=20 > peer interface. >=20 > While coloring within those lines, the next question is=20 > whether there is a single subset that can be defined or=20 > whether there will be many. I am betting on many, probably a=20 > different set for each federation or even bilateral pairing=20 > that might exist. That could be another rabbit hole. > I would be happy if two peers could point to the same subset=20 > and agree to use it, no matter how many subsets might exist. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, May 23, 2006 3:05 PM > > To: 'Francois D. Menard'; Michael Hammer (mhammer); 'Khan, Sohel Q=20 > > [CTO]'; 'David Meyer'; speermint@ietf.org > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering=20 > Architecture > >=20 > > By far the largest mistake EVER made by the IETF in the=20 > development of=20 > > SIP was to allow SIP to be extended to imitate the existing=20 > PSTN. If=20 > > we ever were to start again, the golden rule would be DON'T IMITATE=20 > > THE PSTN, and the corollary would be "Just because the PSTN does it=20 > > that way DOES NOT MEAN it's a good idea". > >=20 > > So, the very idea that "replication of functionality in the > > SS7 minimum message set" is the definition of what we need=20 > to do makes=20 > > me want to puke. > >=20 > > No, and a pox on your houses for even thinking that. > >=20 > > While we're going to start with "basic call", we need to=20 > define those=20 > > call features that must cross domain boundaries. > > Most of them have existing SIP messaging (in sip-examples, for=20 > > instance). We need to make sure those features work across the=20 > > boundary. That has nothing whatsoever to do with an SS7=20 > message. The=20 > > mms might give us clues on what features might be=20 > interesting to put=20 > > on our list, but I'll bet we end up with a lot less of them, and a=20 > > bunch of stuff not in SS7 (or C7); inter-domain presence,=20 > for example. > >=20 > > Brian > >=20 > > -----Original Message----- > > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > > Sent: Tuesday, May 23, 2006 2:50 PM > > To: 'Michael Hammer (mhammer)'; 'Khan, Sohel Q [CTO]';=20 > 'David Meyer';=20 > > speermint@ietf.org > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering=20 > Architecture > >=20 > > > I don't see anything diametrically opposed between what I=20 > suggested=20 > > > and > > what you are suggesting. =20 > >=20 > > I would be satisfied with this: > >=20 > > SPEERMINT compliance requires replication of the functionality=20 > > available in the SS7 minumum message set which can be done by SIP,=20 > > 3323, 3325. Better than SS7 mms functionlality made possible with=20 > > ATIS, IP Sphere or other sip profiles will also be considered as=20 > > SPEERMIT compliant. > >=20 > > > If there is to be an IETF-approved SIP profile, I think it should=20 > > > first be > > decided if that is the turf of the Speermint or the SIP WG. > > Those last two statements are at the heart of my concerns. > >=20 > > SPEERMINT will be completely toothless as an RFC if it just states,=20 > > compliance with SPEERMINT can be achieved by compliance=20 > with non-IETF=20 > > standards. > >=20 > > F. > >=20 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 23 19:59:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FigmP-0003TJ-Pp; Tue, 23 May 2006 19:59:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FigmO-0003TE-MQ for speermint@ietf.org; Tue, 23 May 2006 19:59:12 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FigmN-0003Xl-8B for speermint@ietf.org; Tue, 23 May 2006 19:59:12 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 23 May 2006 19:59:11 -0400 X-IronPort-AV: i="4.05,162,1146456000"; d="scan'208"; a="89302760:sNHT34079712" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4NNxATL007073; Tue, 23 May 2006 19:59:10 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 May 2006 19:59:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 23 May 2006 19:59:08 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3017E6495@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAANiSfAAGpkGw From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , "Brian Rosen" , "Francois D. Menard" , "Khan, Sohel Q [CTO]" , "David Meyer" , X-OriginalArrivalTime: 23 May 2006 23:59:10.0072 (UTC) FILETIME=[E2391780:01C67EC4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org A least common denominator set will likely be small,=20 but perhaps not sufficiently rich for any two wishing to peering. Mike =20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Tuesday, May 23, 2006 4:54 PM > To: Michael Hammer (mhammer); Brian Rosen; Francois D.=20 > Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > >I think the the interworking of SIP to PSTN is out of scope here. >=20 > Yes > I did not find anything about this in the charter. > It is not even mentioned in the out-of-scope section (which=20 > mentions at least H.323 ;-) > =20 > >While coloring within those lines, the next question is=20 > whether there=20 > >is a single subset that can be defined or whether there will=20 > be many. =20 > >I am betting on many, probably a different set for each=20 > federation or=20 > >even bilateral pairing that might exist. > =20 > I always had the idea that we could define minimum=20 > requrements (which could be the overlap of the many subsets)=20 > but maybe I am asking too much Or is SIP already as baroque=20 > at OSI FTAM was? > (where we could only find bilateral "peerings" between DEC,=20 > IBM and Siemens, but not a subset with worked with all three ;-) >=20 > Richard > =20 >=20 > ________________________________ >=20 > Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Gesendet: Di 23.05.2006 22:32 > An: Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO];=20 > David Meyer; speermint@ietf.org > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 >=20 >=20 > Brian, >=20 > I think the the interworking of SIP to PSTN is out of scope=20 > here. The issue is whether two peers, once they have=20 > discovered each other, can know what subset of SIP they need=20 > to support. I don't think there is any need to go down the=20 > rabbit hole on what applications are supported and whether=20 > they are PSTN emulations or simulations or whatever. We may=20 > know in the back of our mind that some application won't work=20 > if RFC X is not supported, but we don't need to discuss that.=20 > We need only to focus on what SIP RFCs are needed on the SIP=20 > peer interface. >=20 > While coloring within those lines, the next question is=20 > whether there is a single subset that can be defined or=20 > whether there will be many. I am betting on many, probably a=20 > different set for each federation or even bilateral pairing=20 > that might exist. That could be another rabbit hole. > I would be happy if two peers could point to the same subset=20 > and agree to use it, no matter how many subsets might exist. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, May 23, 2006 3:05 PM > > To: 'Francois D. Menard'; Michael Hammer (mhammer); 'Khan, Sohel Q=20 > > [CTO]'; 'David Meyer'; speermint@ietf.org > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering=20 > Architecture > > > > By far the largest mistake EVER made by the IETF in the=20 > development of=20 > > SIP was to allow SIP to be extended to imitate the existing=20 > PSTN. If=20 > > we ever were to start again, the golden rule would be DON'T IMITATE=20 > > THE PSTN, and the corollary would be "Just because the PSTN does it=20 > > that way DOES NOT MEAN it's a good idea". > > > > So, the very idea that "replication of functionality in the > > SS7 minimum message set" is the definition of what we need=20 > to do makes=20 > > me want to puke. > > > > No, and a pox on your houses for even thinking that. > > > > While we're going to start with "basic call", we need to=20 > define those=20 > > call features that must cross domain boundaries. > > Most of them have existing SIP messaging (in sip-examples, for=20 > > instance). We need to make sure those features work across the=20 > > boundary. That has nothing whatsoever to do with an SS7=20 > message. The=20 > > mms might give us clues on what features might be=20 > interesting to put=20 > > on our list, but I'll bet we end up with a lot less of them, and a=20 > > bunch of stuff not in SS7 (or C7); inter-domain presence,=20 > for example. > > > > Brian > > > > -----Original Message----- > > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > > Sent: Tuesday, May 23, 2006 2:50 PM > > To: 'Michael Hammer (mhammer)'; 'Khan, Sohel Q [CTO]';=20 > 'David Meyer';=20 > > speermint@ietf.org > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering=20 > Architecture > > > > > I don't see anything diametrically opposed between what I=20 > suggested=20 > > > and > > what you are suggesting.=20 > > > > I would be satisfied with this: > > > > SPEERMINT compliance requires replication of the functionality=20 > > available in the SS7 minumum message set which can be done by SIP,=20 > > 3323, 3325. Better than SS7 mms functionlality made possible with=20 > > ATIS, IP Sphere or other sip profiles will also be considered as=20 > > SPEERMIT compliant. > > > > > If there is to be an IETF-approved SIP profile, I think it should=20 > > > first be > > decided if that is the turf of the Speermint or the SIP WG. > > Those last two statements are at the heart of my concerns. > > > > SPEERMINT will be completely toothless as an RFC if it just states,=20 > > compliance with SPEERMINT can be achieved by compliance=20 > with non-IETF=20 > > standards. > > > > F. > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 23 20:11:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Figxv-0007XZ-9P; Tue, 23 May 2006 20:11:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Figxu-0007XU-9X for speermint@ietf.org; Tue, 23 May 2006 20:11:06 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Figxr-00043w-R8 for speermint@ietf.org; Tue, 23 May 2006 20:11:06 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 23 May 2006 20:11:04 -0400 X-IronPort-AV: i="4.05,162,1146456000"; d="scan'208"; a="89303632:sNHT32984804" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4O0B3TL009466; Tue, 23 May 2006 20:11:03 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 May 2006 20:11:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 23 May 2006 20:11:01 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3017E6499@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcZ+q8WhFsSTLsuNRLCUX0wJJzy1JQAGVEzA From: "Michael Hammer \(mhammer\)" To: "Otmar Lendl" X-OriginalArrivalTime: 24 May 2006 00:11:03.0050 (UTC) FILETIME=[8B30E6A0:01C67EC6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: speermint@ietf.org, "Khan, Sohel Q \[CTO\]" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Otmar, I did read one of your drafts, but had doubts about whether all this policy data should be pushed in the DNS. =20 I was wondering whether the DNS could be used to discover: - that a particular user is served by a particular service provider, and=20 - that service provider has a URI to which the originating SP can subscribe to get further information, and - that information says the terminating SP can support peering with =3D federation subset A, or=20 =3D federation subset B, or ... I suppose that policy document could list all the RFCs you support and then spend time figuring out what matches and what doesn't. But I would wonder how well each permutation has been tested. Mike > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at]=20 > Sent: Tuesday, May 23, 2006 4:59 PM > To: Michael Hammer (mhammer) > Cc: Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO];=20 > David Meyer; speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > On 2006/05/23 22:05, "Michael Hammer (mhammer)"=20 > wrote: > >=20 > > I think the the interworking of SIP to PSTN is out of scope=20 > here. The=20 > > issue is whether two peers, once they have discovered each=20 > other, can=20 > > know what subset of SIP they need to support. > [...] > > While coloring within those lines, the next question is=20 > whether there=20 > > is a single subset that can be defined or whether there=20 > will be many. =20 > > I am betting on many, probably a different set for each=20 > federation or=20 > > even bilateral pairing that might exist. That could be=20 > another rabbit hole. > > I would be happy if two peers could point to the same=20 > subset and agree=20 > > to use it, no matter how many subsets might exist. >=20 > Well, I've got a draft to sell to you. >=20 > From the example section of draft-lendl-domain-policy-ddds-00.txt: >=20 > o If the carrier example.com only accepts SIP calls (in=20 > addition to > PSTN interconnect) if the PSTN emulation is good, he=20 > might publish > a policy like this: >=20 > $ORIGIN example.com. > ; order pref flags service regexp replacement > IN NAPTR 10 10 "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:3578!" . > IN NAPTR 10 11 "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:3666!" . > IN NAPTR 10 12 "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:3960!" . >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 23 20:27:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FihD5-0004pN-HX; Tue, 23 May 2006 20:26:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FihD3-0004pI-M5 for speermint@ietf.org; Tue, 23 May 2006 20:26:45 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FihD2-0004so-DX for speermint@ietf.org; Tue, 23 May 2006 20:26:45 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 23 May 2006 20:26:44 -0400 X-IronPort-AV: i="4.05,162,1146456000"; d="scan'208"; a="89304618:sNHT33659120" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4O0QhvF002396; Tue, 23 May 2006 20:26:44 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 May 2006 20:26:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 May 2006 20:26:42 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3017E64A2@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SPEERMINT Peering Architecture - LF - OF - SF Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAATumxgAG4BNw From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , "Brian Rosen" , "Francois D. Menard" , "Khan, Sohel Q [CTO]" , "David Meyer" , X-OriginalArrivalTime: 24 May 2006 00:26:43.0275 (UTC) FILETIME=[BB9BD9B0:01C67EC8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Subject: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Richard, Let me turn this around to you. How much policy data do you stuff into ENUM? How general a database do you expect DNS to become? Do you expect that all peers will be pointed to the same entry point into the network? The thought was that before you blast the SF with INVITEs, it might be useful to learn something about the nature of the interface expectations. For the most part these are bins into which things can be organized while this group gets started. If later it is concluded a bin isn't needed, then it can be removed and whatever was collected handled by some other bin. Mike =20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Tuesday, May 23, 2006 5:09 PM > To: Michael Hammer (mhammer); Brian Rosen; Francois D.=20 > Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > Subject: SPEERMINT Peering Architecture - LF - OF - SF >=20 > Folks, > =20 > One general statement in advance: > Coming from the VON Europe last week with discussions about=20 > walled garden and IMS, my overall expression is that this=20 > draft in IMS in text-mode. > =20 > I have another question for clarification to this draft,=20 > because I am confused: > =20 > I do not understand that the LF is discovering the OF >=20 > o Location Function (LF): Purpose is to enable discovery=20 > of the OF=20 > peering point.=20 >=20 > o Operation Function (OF): Purpose is to enable discovery and=20 > exchange of policy and parameters to be used in with the SF=20 > peering point.=20 >=20 > o Signaling Function (SF): Purpose is to enable the discovery of=20 > endpoints and assist in discovery and exchange of=20 > parameters to be=20 > used with the MF peering point.=20 >=20 > I always had the naive idea (also triggered by the SPEERMINT=20 > chartert that e.g. ENUM is a LF and discovering the SIP URIs=20 > uses in the SF >=20 > How is now OF coming in between thsi, especially what is=20 > listed in the draft, especially CALEA, Accounting and Applications? >=20 > "Operational data mediation: TBD=20 >=20 > o CALEA implementation: TBD=20 >=20 > o Accounting: Call Detail Record's (CDR's) MAY be=20 > collected to be=20 > utilized by the peering operators. Based on the=20 > application, the=20 > format should be an open standard for common consumption of=20 > billing systems. Operators may use this data for a number of=20 > reasons, including billing in the event the peering=20 > relationship=20 > becomes asymmetric (unbalanced traffic flow) or there=20 > is a Tier 1=20 > to Tier 2 relationship. In order to limit the potential for=20 > billing systems to impact the OF, a separate server should be=20 > created to maintain all records collected from a single=20 > interconnection to any number of OF's.=20 > An OF can also be a special function that contains bi-laterally=20 > disclosed information about the application servers and=20 > databases of=20 > each IP service provider. An example of this function is=20 > to allow a=20 > session to select a better suited application server from a set of=20 > application servers located inside both service providers'=20 > network. " > =20 > Richard >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 24 01:42:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fim8V-0001aX-K7; Wed, 24 May 2006 01:42:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fim8T-0001aS-QD for speermint@ietf.org; Wed, 24 May 2006 01:42:21 -0400 Received: from mail.ask4internet.com ([213.249.149.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fim8R-0002S9-Fv for speermint@ietf.org; Wed, 24 May 2006 01:42:21 -0400 Received: from RSHOCKEYLTXP (unverified [193.67.186.130]) by mail.ask4internet.com (Vircom SMTPRS 5.1.202) with ESMTP id ; Wed, 24 May 2006 06:38:02 +0100 From: "Richard Shockey" To: "'Brian Rosen'" , "'Francois D. Menard'" , "'Michael Hammer \(mhammer\)'" , "'Khan, Sohel Q [CTO]'" , "'David Meyer'" , Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Wed, 24 May 2006 01:42:18 -0400 Message-ID: <006e01c67ef4$d1e71460$5400000a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswABaMIlA= In-Reply-To: <09d001c67e9b$bb2850d0$640fa8c0@cis.neustar.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > > So, the very idea that "replication of functionality in the SS7 minimum > message set" is the definition of what we need to do makes me want to > puke. > > No, and a pox on your houses for even thinking that. > I'm thinking of extending my NO SS7 NO TCAP hats to entire clothing line ...NO PSTN > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 24 01:46:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FimBy-0002Fx-Nl; Wed, 24 May 2006 01:45:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FimBx-0002Fq-HV for speermint@ietf.org; Wed, 24 May 2006 01:45:57 -0400 Received: from mail.ask4internet.com ([213.249.149.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FimBw-0002aX-0i for speermint@ietf.org; Wed, 24 May 2006 01:45:57 -0400 Received: from RSHOCKEYLTXP (unverified [193.67.186.130]) by mail.ask4internet.com (Vircom SMTPRS 5.1.202) with ESMTP id ; Wed, 24 May 2006 06:41:39 +0100 From: "Richard Shockey" To: "'Michael Hammer \(mhammer\)'" , "'Brian Rosen'" , "'Francois D. Menard'" , "'Khan, Sohel Q [CTO]'" , "'David Meyer'" , Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Wed, 24 May 2006 01:45:54 -0400 Message-ID: <006f01c67ef5$53141470$5400000a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAE5hPcA== In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3017E63F0@xmb-rtp-20b.amer.cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Tuesday, May 23, 2006 4:32 PM > To: Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer; > speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > Brian, > > I think the the interworking of SIP to PSTN is out of scope here. The > issue is whether two peers, once they have discovered each other, can > know what subset of SIP they need to support. Oh goodie ... finally we can get the SIP working group to try and define a rational set of SIP Profiles so SPEETMINT can use them do discover what subsets of SIP they can support. Talk about going down black holes ... > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 24 04:14:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FioVo-0003Nc-JC; Wed, 24 May 2006 04:14:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FioVn-0003NX-78 for speermint@ietf.org; Wed, 24 May 2006 04:14:35 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FioVm-0001Vi-Hi for speermint@ietf.org; Wed, 24 May 2006 04:14:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Wed, 24 May 2006 10:18:37 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4FD6@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAANiSfAAGpkGwABFyNDA= From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" , "Brian Rosen" , "Francois D. Menard" , "Khan, Sohel Q [CTO]" , "David Meyer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > A least common denominator set will likely be small, > but perhaps not sufficiently rich for any two wishing to peering. >=20 e.g. RFC3261 and 3263 ;-) plus TLS and one kind of asserted identity additional richness could be provided by policy records Richard > Mike >=20 >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Tuesday, May 23, 2006 4:54 PM > > To: Michael Hammer (mhammer); Brian Rosen; Francois D. > > Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > >I think the the interworking of SIP to PSTN is out of scope here. > > > > Yes > > I did not find anything about this in the charter. > > It is not even mentioned in the out-of-scope section (which > > mentions at least H.323 ;-) > > > > >While coloring within those lines, the next question is > > whether there > > >is a single subset that can be defined or whether there will > > be many. > > >I am betting on many, probably a different set for each > > federation or > > >even bilateral pairing that might exist. > > > > I always had the idea that we could define minimum > > requrements (which could be the overlap of the many subsets) > > but maybe I am asking too much Or is SIP already as baroque > > at OSI FTAM was? > > (where we could only find bilateral "peerings" between DEC, > > IBM and Siemens, but not a subset with worked with all three ;-) > > > > Richard > > > > > > ________________________________ > > > > Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Gesendet: Di 23.05.2006 22:32 > > An: Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; > > David Meyer; speermint@ietf.org > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > > > > > Brian, > > > > I think the the interworking of SIP to PSTN is out of scope > > here. The issue is whether two peers, once they have > > discovered each other, can know what subset of SIP they need > > to support. I don't think there is any need to go down the > > rabbit hole on what applications are supported and whether > > they are PSTN emulations or simulations or whatever. We may > > know in the back of our mind that some application won't work > > if RFC X is not supported, but we don't need to discuss that. > > We need only to focus on what SIP RFCs are needed on the SIP > > peer interface. > > > > While coloring within those lines, the next question is > > whether there is a single subset that can be defined or > > whether there will be many. I am betting on many, probably a > > different set for each federation or even bilateral pairing > > that might exist. That could be another rabbit hole. > > I would be happy if two peers could point to the same subset > > and agree to use it, no matter how many subsets might exist. > > > > Mike > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Tuesday, May 23, 2006 3:05 PM > > > To: 'Francois D. Menard'; Michael Hammer (mhammer); 'Khan, Sohel Q > > > [CTO]'; 'David Meyer'; speermint@ietf.org > > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering > > Architecture > > > > > > By far the largest mistake EVER made by the IETF in the > > development of > > > SIP was to allow SIP to be extended to imitate the existing > > PSTN. If > > > we ever were to start again, the golden rule would be DON'T IMITATE > > > THE PSTN, and the corollary would be "Just because the PSTN does it > > > that way DOES NOT MEAN it's a good idea". > > > > > > So, the very idea that "replication of functionality in the > > > SS7 minimum message set" is the definition of what we need > > to do makes > > > me want to puke. > > > > > > No, and a pox on your houses for even thinking that. > > > > > > While we're going to start with "basic call", we need to > > define those > > > call features that must cross domain boundaries. > > > Most of them have existing SIP messaging (in sip-examples, for > > > instance). We need to make sure those features work across the > > > boundary. That has nothing whatsoever to do with an SS7 > > message. The > > > mms might give us clues on what features might be > > interesting to put > > > on our list, but I'll bet we end up with a lot less of them, and a > > > bunch of stuff not in SS7 (or C7); inter-domain presence, > > for example. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > > > Sent: Tuesday, May 23, 2006 2:50 PM > > > To: 'Michael Hammer (mhammer)'; 'Khan, Sohel Q [CTO]'; > > 'David Meyer'; > > > speermint@ietf.org > > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering > > Architecture > > > > > > > I don't see anything diametrically opposed between what I > > suggested > > > > and > > > what you are suggesting. > > > > > > I would be satisfied with this: > > > > > > SPEERMINT compliance requires replication of the functionality > > > available in the SS7 minumum message set which can be done by SIP, > > > 3323, 3325. Better than SS7 mms functionlality made possible with > > > ATIS, IP Sphere or other sip profiles will also be considered as > > > SPEERMIT compliant. > > > > > > > If there is to be an IETF-approved SIP profile, I think it should > > > > first be > > > decided if that is the turf of the Speermint or the SIP WG. > > > Those last two statements are at the heart of my concerns. > > > > > > SPEERMINT will be completely toothless as an RFC if it just states, > > > compliance with SPEERMINT can be achieved by compliance > > with non-IETF > > > standards. > > > > > > F. > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 24 04:33:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fionw-0002Q8-E2; Wed, 24 May 2006 04:33:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fionv-0002P6-9K for speermint@ietf.org; Wed, 24 May 2006 04:33:19 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fiont-0001yE-O3 for speermint@ietf.org; Wed, 24 May 2006 04:33:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 May 2006 10:37:23 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4FD7@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SPEERMINT Peering Architecture - LF - OF - SF Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAATumxgAG4BNwABEZoVA= From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" , "Brian Rosen" , "Francois D. Menard" , "Khan, Sohel Q [CTO]" , "David Meyer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: Subject: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Michael, >=20 > Let me turn this around to you. Good policy, answering a questing with another question ;-) >=20 > How much policy data do you stuff into ENUM? None, the basic idea of Infrastructure ENUM (which will be used for service providers is to provide a domain name in a SIP URI =3D a service provider ID (SPID) >=20 > How general a database do you expect DNS to become? Good question. The DNS is reliable, scalable and fast and it is available. So IMHO if some information is needed in some kind of database, DNS is the first choice (public and/or private DNS) >=20 > Do you expect that all peers will be pointed to the same entry point > into the network? I assume with network you mean the destination "network"? The answer is no, =20 > The thought was that before you blast the SF with INVITEs, it might be > useful to learn something about the nature of the interface > expectations. =20 Agreed, I would suggest to rename OF to PF (Policy detection Function) IMHO the short description is ok Operation Function (OF): Purpose is to enable discovery and > > exchange of policy and parameters to be used in with the SF > > peering point. the long description mentioning CALEA and Accounting is a bit misleading an needs rewording. Especially the negotiation of application servers is a bit early at this time. >For the most part these are bins into which things can be > organized while this group gets started. If later it is concluded a bin > isn't needed, then it can be removed and whatever was collected handled > by some other bin. Ok Richard >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Tuesday, May 23, 2006 5:09 PM > > To: Michael Hammer (mhammer); Brian Rosen; Francois D. > > Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > > Subject: SPEERMINT Peering Architecture - LF - OF - SF > > > > Folks, > > > > One general statement in advance: > > Coming from the VON Europe last week with discussions about > > walled garden and IMS, my overall expression is that this > > draft in IMS in text-mode. > > > > I have another question for clarification to this draft, > > because I am confused: > > > > I do not understand that the LF is discovering the OF > > > > o Location Function (LF): Purpose is to enable discovery > > of the OF > > peering point. > > > > o Operation Function (OF): Purpose is to enable discovery and > > exchange of policy and parameters to be used in with the SF > > peering point. > > > > o Signaling Function (SF): Purpose is to enable the discovery of > > endpoints and assist in discovery and exchange of > > parameters to be > > used with the MF peering point. > > > > I always had the naive idea (also triggered by the SPEERMINT > > chartert that e.g. ENUM is a LF and discovering the SIP URIs > > uses in the SF > > > > How is now OF coming in between thsi, especially what is > > listed in the draft, especially CALEA, Accounting and Applications? > > > > "Operational data mediation: TBD > > > > o CALEA implementation: TBD > > > > o Accounting: Call Detail Record's (CDR's) MAY be > > collected to be > > utilized by the peering operators. Based on the > > application, the > > format should be an open standard for common consumption of > > billing systems. Operators may use this data for a number of > > reasons, including billing in the event the peering > > relationship > > becomes asymmetric (unbalanced traffic flow) or there > > is a Tier 1 > > to Tier 2 relationship. In order to limit the potential for > > billing systems to impact the OF, a separate server should be > > created to maintain all records collected from a single > > interconnection to any number of OF's. > > An OF can also be a special function that contains bi-laterally > > disclosed information about the application servers and > > databases of > > each IP service provider. An example of this function is > > to allow a > > session to select a better suited application server from a set of > > application servers located inside both service providers' > > network. " > > > > Richard > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 24 07:30:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FirYs-0007da-Rs; Wed, 24 May 2006 07:29:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FirYq-0007dV-VU for speermint@ietf.org; Wed, 24 May 2006 07:29:56 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FirYo-0000nC-6O for speermint@ietf.org; Wed, 24 May 2006 07:29:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Wed, 24 May 2006 13:33:55 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A64@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAANiSfAAGpkGwABFyNDAABcvUoAAA7iiQ From: "Stastny Richard" To: "Francois D. Menard" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org >Yes, and presentation restriction, >So 3261, 3263, 3325 and 3326. >Sold! Bought! ;-) If anybody has any additions to this (for minimum requirements), he may holler IMHO in addition a BCP on the population of the header fields, particularly in context with phone numbers (e.164 and non-E.164) is required. A BCP on how to establish two-way TLS may also be useful Richard ________________________________ Von: Francois D. Menard [mailto:fmenard@xittelecom.com] Gesendet: Mi 24.05.2006 13:03 An: Stastny Richard Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Yes, and presentation restriction, So 3261, 3263, 3325 and 3326. Sold! F. -- Fran=E7ois D. M=E9nard Charg=E9 de projet Xit t=E9l=E9com inc. 1350 rue Royale #800 Trois-Rivi=E8res, QC, G9A 4J4 Canada fmenard@xittelecom.com Tel: (819) 374-2556 ext. 268 Fax: (819) 374-0395 Cell: (819) 692-1383 -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: 24 mai 2006 04:19 To: Michael Hammer (mhammer); Brian Rosen; Francois D. Menard; Khan, = Sohel Q [CTO]; David Meyer; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > A least common denominator set will likely be small, but perhaps not > sufficiently rich for any two wishing to peering. > e.g. RFC3261 and 3263 ;-) plus TLS and one kind of asserted identity additional richness could be provided by policy records Richard > Mike > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Tuesday, May 23, 2006 4:54 PM > > To: Michael Hammer (mhammer); Brian Rosen; Francois D. > > Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > >I think the the interworking of SIP to PSTN is out of scope here. > > > > Yes > > I did not find anything about this in the charter. > > It is not even mentioned in the out-of-scope section (which mentions > > at least H.323 ;-) > > > > >While coloring within those lines, the next question is > > whether there > > >is a single subset that can be defined or whether there will > > be many. > > >I am betting on many, probably a different set for each > > federation or > > >even bilateral pairing that might exist. > > > > I always had the idea that we could define minimum requrements > > (which could be the overlap of the many subsets) but maybe I am > > asking too much Or is SIP already as baroque at OSI FTAM was? > > (where we could only find bilateral "peerings" between DEC, IBM and > > Siemens, but not a subset with worked with all three ;-) > > > > Richard > > > > > > ________________________________ > > > > Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Gesendet: Di 23.05.2006 22:32 > > An: Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David > > Meyer; speermint@ietf.org > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > > > > > Brian, > > > > I think the the interworking of SIP to PSTN is out of scope here.=20 > > The issue is whether two peers, once they have discovered each > > other, can know what subset of SIP they need to support. I don't > > think there is any need to go down the rabbit hole on what > > applications are supported and whether they are PSTN emulations or > > simulations or whatever. We may know in the back of our mind that > > some application won't work if RFC X is not supported, but we don't > > need to discuss that. > > We need only to focus on what SIP RFCs are needed on the SIP peer > > interface. > > > > While coloring within those lines, the next question is whether > > there is a single subset that can be defined or whether there will > > be many. I am betting on many, probably a different set for each > > federation or even bilateral pairing that might exist. That could > > be another rabbit hole. > > I would be happy if two peers could point to the same subset and > > agree to use it, no matter how many subsets might exist. > > > > Mike > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Tuesday, May 23, 2006 3:05 PM > > > To: 'Francois D. Menard'; Michael Hammer (mhammer); 'Khan, Sohel Q > > > [CTO]'; 'David Meyer'; speermint@ietf.org > > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering > > Architecture > > > > > > By far the largest mistake EVER made by the IETF in the > > development of > > > SIP was to allow SIP to be extended to imitate the existing > > PSTN. If > > > we ever were to start again, the golden rule would be DON'T IMITATE > > > THE PSTN, and the corollary would be "Just because the PSTN does it > > > that way DOES NOT MEAN it's a good idea". > > > > > > So, the very idea that "replication of functionality in the > > > SS7 minimum message set" is the definition of what we need > > to do makes > > > me want to puke. > > > > > > No, and a pox on your houses for even thinking that. > > > > > > While we're going to start with "basic call", we need to > > define those > > > call features that must cross domain boundaries. > > > Most of them have existing SIP messaging (in sip-examples, for > > > instance). We need to make sure those features work across the > > > boundary. That has nothing whatsoever to do with an SS7 > > message. The > > > mms might give us clues on what features might be > > interesting to put > > > on our list, but I'll bet we end up with a lot less of them, and a > > > bunch of stuff not in SS7 (or C7); inter-domain presence, > > for example. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > > > Sent: Tuesday, May 23, 2006 2:50 PM > > > To: 'Michael Hammer (mhammer)'; 'Khan, Sohel Q [CTO]'; > > 'David Meyer'; > > > speermint@ietf.org > > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering > > Architecture > > > > > > > I don't see anything diametrically opposed between what I > > suggested > > > > and > > > what you are suggesting. > > > > > > I would be satisfied with this: > > > > > > SPEERMINT compliance requires replication of the functionality > > > available in the SS7 minumum message set which can be done by SIP, > > > 3323, 3325. Better than SS7 mms functionlality made possible with > > > ATIS, IP Sphere or other sip profiles will also be considered as > > > SPEERMIT compliant. > > > > > > > If there is to be an IETF-approved SIP profile, I think it should > > > > first be > > > decided if that is the turf of the Speermint or the SIP WG. > > > Those last two statements are at the heart of my concerns. > > > > > > SPEERMINT will be completely toothless as an RFC if it just states, > > > compliance with SPEERMINT can be achieved by compliance > > with non-IETF > > > standards. > > > > > > F. > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 24 07:44:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FirmU-0004kJ-EG; Wed, 24 May 2006 07:44:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FirmT-0004kB-Kf for speermint@ietf.org; Wed, 24 May 2006 07:44:01 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FirmS-0001Xm-A1 for speermint@ietf.org; Wed, 24 May 2006 07:44:01 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 3BC2D1A3A4; Wed, 24 May 2006 13:43:59 +0200 (CEST) Date: Wed, 24 May 2006 13:43:58 +0200 From: Otmar Lendl To: "Michael Hammer (mhammer)" Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Message-ID: <20060524114358.GC1811@nic.at> Mail-Followup-To: Otmar Lendl , "Michael Hammer (mhammer)" , speermint@ietf.org, "Khan, Sohel Q [CTO]" References: <072C5B76F7CEAB488172C6F64B30B5E3017E6499@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3017E6499@xmb-rtp-20b.amer.cisco.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: "Khan, Sohel Q \[CTO\]" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Michael, On 2006/05/24 02:05, "Michael Hammer (mhammer)" wrote: > > I did read one of your drafts, but had doubts about whether all this > policy data should be pushed in the DNS. Well, if the policy is to big, then the DNS can contain a URL which points to the large policy. See the last example in draft-lendl-domain-policy-ddds. > I was wondering whether the DNS could be used to discover: > - that a particular user is served by a particular service provider, Is the user identified by E.164 number or by SIP URI? If the latter, then my draft says: * either the domain part of the SIP URI is the provider's ID, or * a non-terminal NAPTR in the customer's domain points to the provider's domain where the real policy is stored. (if the former, then ENUM is used first) > and > - that service provider has a URI to which the originating SP can > subscribe to get further information, and That fits in nicely with my draft. You just need to define a policy-type for this subscription information. > - that information says the terminating SP can support peering with > = federation subset A, or > = federation subset B, or ... Ok; if this list is long, then an external document is fine. If it is very short, I prefer storing it in the DNS and skip one step at call setup time. If these are just named subsets, then the DNS need only store the name of the subset and not the list of RFC and BCPs. > I suppose that policy document could list all the RFCs you support and > then spend time figuring out what matches and what doesn't. But I would > wonder how well each permutation has been tested. That problem is independent of whether you store the requirement list in the DNS or retrieve it via different means. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 24 10:06:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fitzy-0006MG-Uk; Wed, 24 May 2006 10:06:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fitzx-0006Dj-58 for speermint@ietf.org; Wed, 24 May 2006 10:06:05 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fitzv-0000Sx-S2 for speermint@ietf.org; Wed, 24 May 2006 10:06:05 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 24 May 2006 07:06:04 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,167,1146466800"; d="scan'208"; a="28808499:sNHT23067328" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4OE62vF011471; Wed, 24 May 2006 10:06:02 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 May 2006 10:06:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Wed, 24 May 2006 10:06:01 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3017E6581@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAE5hPcAARjOGg From: "Michael Hammer \(mhammer\)" To: , "Brian Rosen" , "Francois D. Menard" , "Khan, Sohel Q [CTO]" , "David Meyer" , X-OriginalArrivalTime: 24 May 2006 14:06:02.0664 (UTC) FILETIME=[30E35280:01C67F3B] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Which is why I didn't want to get into that business, but leave it to the SIP WG to do, if they thought it worthwhile. Thus, my reference to the hitchiker's guide. Mike > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us]=20 > Sent: Wednesday, May 24, 2006 1:46 AM > To: Michael Hammer (mhammer); 'Brian Rosen'; 'Francois D.=20 > Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 >=20 >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Tuesday, May 23, 2006 4:32 PM > > To: Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO];=20 > David Meyer;=20 > > speermint@ietf.org > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering=20 > Architecture > >=20 > > Brian, > >=20 > > I think the the interworking of SIP to PSTN is out of scope=20 > here. The=20 > > issue is whether two peers, once they have discovered each=20 > other, can=20 > > know what subset of SIP they need to support. >=20 > Oh goodie ... finally we can get the SIP working group to try=20 > and define a rational set of SIP Profiles so SPEETMINT can=20 > use them do discover what subsets of SIP they can support. >=20 > Talk about going down black holes ... >=20 >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 24 10:07:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiu1J-0007SF-Gq; Wed, 24 May 2006 10:07:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiu1I-0007SA-F2 for speermint@ietf.org; Wed, 24 May 2006 10:07:28 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fiu1H-0000Wt-1a for speermint@ietf.org; Wed, 24 May 2006 10:07:28 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 24 May 2006 07:07:26 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,167,1146466800"; d="scan'208"; a="28808663:sNHT28612600" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4OE7FvH011760; Wed, 24 May 2006 10:07:25 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 May 2006 10:07:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Wed, 24 May 2006 10:07:18 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3017E6585@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAANiSfAAGpkGwABFyNDAADD8hYA== From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , "Brian Rosen" , "Francois D. Menard" , "Khan, Sohel Q [CTO]" , "David Meyer" , X-OriginalArrivalTime: 24 May 2006 14:07:19.0991 (UTC) FILETIME=[5EFA7C70:01C67F3B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org My thought was to put it all in the policy records, and point to them with a 10-foot pole. :) Mike > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Wednesday, May 24, 2006 4:19 AM > To: Michael Hammer (mhammer); Brian Rosen; Francois D.=20 > Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 >=20 > > A least common denominator set will likely be small, but=20 > perhaps not=20 > > sufficiently rich for any two wishing to peering. > >=20 > e.g. RFC3261 and 3263 ;-) >=20 > plus TLS and one kind of asserted identity >=20 > additional richness could be provided by policy records >=20 > Richard >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Tuesday, May 23, 2006 4:54 PM > > > To: Michael Hammer (mhammer); Brian Rosen; Francois D. > > > Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > > > > > > >I think the the interworking of SIP to PSTN is out of scope here. > > > > > > Yes > > > I did not find anything about this in the charter. > > > It is not even mentioned in the out-of-scope section=20 > (which mentions=20 > > > at least H.323 ;-) > > > > > > >While coloring within those lines, the next question is > > > whether there > > > >is a single subset that can be defined or whether there will > > > be many. > > > >I am betting on many, probably a different set for each > > > federation or > > > >even bilateral pairing that might exist. > > > > > > I always had the idea that we could define minimum requrements=20 > > > (which could be the overlap of the many subsets) but maybe I am=20 > > > asking too much Or is SIP already as baroque at OSI FTAM was? > > > (where we could only find bilateral "peerings" between=20 > DEC, IBM and=20 > > > Siemens, but not a subset with worked with all three ;-) > > > > > > Richard > > > > > > > > > ________________________________ > > > > > > Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > Gesendet: Di 23.05.2006 22:32 > > > An: Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David=20 > > > Meyer; speermint@ietf.org > > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > > > > > > > > > > > > Brian, > > > > > > I think the the interworking of SIP to PSTN is out of=20 > scope here. =20 > > > The issue is whether two peers, once they have discovered each=20 > > > other, can know what subset of SIP they need to support. I don't=20 > > > think there is any need to go down the rabbit hole on what=20 > > > applications are supported and whether they are PSTN=20 > emulations or=20 > > > simulations or whatever. We may know in the back of our=20 > mind that=20 > > > some application won't work if RFC X is not supported,=20 > but we don't=20 > > > need to discuss that. > > > We need only to focus on what SIP RFCs are needed on the=20 > SIP peer=20 > > > interface. > > > > > > While coloring within those lines, the next question is whether=20 > > > there is a single subset that can be defined or whether=20 > there will=20 > > > be many. I am betting on many, probably a different set for each=20 > > > federation or even bilateral pairing that might exist. =20 > That could=20 > > > be another rabbit hole. > > > I would be happy if two peers could point to the same subset and=20 > > > agree to use it, no matter how many subsets might exist. > > > > > > Mike > > > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Tuesday, May 23, 2006 3:05 PM > > > > To: 'Francois D. Menard'; Michael Hammer (mhammer);=20 > 'Khan, Sohel Q=20 > > > > [CTO]'; 'David Meyer'; speermint@ietf.org > > > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering > > > Architecture > > > > > > > > By far the largest mistake EVER made by the IETF in the > > > development of > > > > SIP was to allow SIP to be extended to imitate the existing > > > PSTN. If > > > > we ever were to start again, the golden rule would be DON'T > IMITATE > > > > THE PSTN, and the corollary would be "Just because the PSTN does > it > > > > that way DOES NOT MEAN it's a good idea". > > > > > > > > So, the very idea that "replication of functionality in the > > > > SS7 minimum message set" is the definition of what we need > > > to do makes > > > > me want to puke. > > > > > > > > No, and a pox on your houses for even thinking that. > > > > > > > > While we're going to start with "basic call", we need to > > > define those > > > > call features that must cross domain boundaries. > > > > Most of them have existing SIP messaging (in sip-examples, for=20 > > > > instance). We need to make sure those features work across the=20 > > > > boundary. That has nothing whatsoever to do with an SS7 > > > message. The > > > > mms might give us clues on what features might be > > > interesting to put > > > > on our list, but I'll bet we end up with a lot less of=20 > them, and a=20 > > > > bunch of stuff not in SS7 (or C7); inter-domain presence, > > > for example. > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > > > > Sent: Tuesday, May 23, 2006 2:50 PM > > > > To: 'Michael Hammer (mhammer)'; 'Khan, Sohel Q [CTO]'; > > > 'David Meyer'; > > > > speermint@ietf.org > > > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering > > > Architecture > > > > > > > > > I don't see anything diametrically opposed between what I > > > suggested > > > > > and > > > > what you are suggesting. > > > > > > > > I would be satisfied with this: > > > > > > > > SPEERMINT compliance requires replication of the functionality=20 > > > > available in the SS7 minumum message set which can be=20 > done by SIP,=20 > > > > 3323, 3325. Better than SS7 mms functionlality made=20 > possible with=20 > > > > ATIS, IP Sphere or other sip profiles will also be=20 > considered as=20 > > > > SPEERMIT compliant. > > > > > > > > > If there is to be an IETF-approved SIP profile, I think it > should > > > > > first be > > > > decided if that is the turf of the Speermint or the SIP WG. > > > > Those last two statements are at the heart of my concerns. > > > > > > > > SPEERMINT will be completely toothless as an RFC if it just > states, > > > > compliance with SPEERMINT can be achieved by compliance > > > with non-IETF > > > > standards. > > > > > > > > F. > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 24 10:22:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiuFJ-00035K-Tv; Wed, 24 May 2006 10:21:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiuFI-00035F-RH for speermint@ietf.org; Wed, 24 May 2006 10:21:56 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiuFG-0001I1-IE for speermint@ietf.org; Wed, 24 May 2006 10:21:56 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 24 May 2006 07:21:55 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,167,1146466800"; d="scan'208"; a="28810717:sNHT24119316" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4OELrTL027485; Wed, 24 May 2006 10:21:53 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 May 2006 10:21:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Wed, 24 May 2006 10:21:52 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3017E6597@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcZ/J15wu/Ba/2sNTLCXUP/3hHYAhQAFEQbg From: "Michael Hammer \(mhammer\)" To: "Otmar Lendl" X-OriginalArrivalTime: 24 May 2006 14:21:53.0586 (UTC) FILETIME=[67AE8120:01C67F3D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: "Khan, Sohel Q \[CTO\]" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Otmar, I think our main difference is that I am suspecting that the policy will be large and possibly very dynamic, thus less suitable for locating in DNS. Also, instead of pointing directly to a single policy document, which seems like a one-size-fits-all periodic user poll option,; rather, use Subscriptions where the resulting document may depend on authentication and who is asking, and can be pushed on the schedule of the server when the policy changes. These are just suggestions being thrown out for discussion. I'd like to hear what folks think about them. I'm also questioning how much information about SIP needs to be embedded in other protocols like DNS, DHCP, etc. and how much might be more cohesive if handled via SIP-based mechanisms. Finding the right balance, if you will. Mike > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at]=20 > Sent: Wednesday, May 24, 2006 7:44 AM > To: Michael Hammer (mhammer) > Cc: speermint@ietf.org; Khan, Sohel Q [CTO] > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 >=20 > Michael, >=20 > On 2006/05/24 02:05, "Michael Hammer (mhammer)"=20 > wrote: > >=20 > > I did read one of your drafts, but had doubts about whether=20 > all this=20 > > policy data should be pushed in the DNS. >=20 > Well, if the policy is to big, then the DNS can contain a URL=20 > which points to the large policy. See the last example in=20 > draft-lendl-domain-policy-ddds. >=20 > > I was wondering whether the DNS could be used to discover: > > - that a particular user is served by a particular service=20 > provider, >=20 > Is the user identified by E.164 number or by SIP URI? >=20 > If the latter, then my draft says: >=20 > * either the domain part of the SIP URI is the provider's ID, or >=20 > * a non-terminal NAPTR in the customer's domain points to the > provider's domain where the real policy is stored. >=20 > (if the former, then ENUM is used first) >=20 > > and > > - that service provider has a URI to which the originating SP can=20 > > subscribe to get further information, and >=20 > That fits in nicely with my draft. You just need to define a=20 > policy-type for this subscription information. >=20 > > - that information says the terminating SP can support peering with > > =3D federation subset A, or=20 > > =3D federation subset B, or ... >=20 > Ok; if this list is long, then an external document is fine.=20 > If it is very short, I prefer storing it in the DNS and skip=20 > one step at call setup time. >=20 > If these are just named subsets, then the DNS need only store=20 > the name of the subset and not the list of RFC and BCPs. >=20 > > I suppose that policy document could list all the RFCs you=20 > support and=20 > > then spend time figuring out what matches and what doesn't. But I=20 > > would wonder how well each permutation has been tested. >=20 > That problem is independent of whether you store the=20 > requirement list in the DNS or retrieve it via different means. >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 24 10:47:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiudR-0003Tf-2D; Wed, 24 May 2006 10:46:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiudQ-0003Ta-Kc for speermint@ietf.org; Wed, 24 May 2006 10:46:52 -0400 Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiudP-0002hZ-8F for speermint@ietf.org; Wed, 24 May 2006 10:46:52 -0400 Received: (qmail 1077 invoked by uid 510); 24 May 2006 10:25:13 -0400 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(24.1.140.191):. Processed in 1.598628 secs); 24 May 2006 14:25:13 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(24.1.140.191):. Processed in 1.598628 secs Process 1054) Received: from c-24-1-140-191.hsd1.tx.comcast.net (HELO DSX400) (henry@pulver.com@24.1.140.191) by 192.246.69.184 with SMTP; Wed, 24 May 2006 14:25:11 +0000 From: "Henry Sinnreich" To: "'Michael Hammer \(mhammer\)'" , "'Otmar Lendl'" Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Wed, 24 May 2006 09:46:46 -0500 Organization: pulver.com Message-ID: <000b01c67f40$e3064030$2800a8c0@DSX400> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ/J15wu/Ba/2sNTLCXUP/3hHYAhQAFEQbgAAESENA= In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3017E6597@xmb-rtp-20b.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: "'Khan, Sohel Q \[CTO\]'" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I believe Mike is right on track. Overloading the DNS with application protocol information, such as detailed policies for SIP is not what the DNS was designed for. Going further down this path would make the DNS a successor of the AIN! Thanks, Henry -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Wednesday, May 24, 2006 9:22 AM To: Otmar Lendl Cc: Khan, Sohel Q [CTO]; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Otmar, I think our main difference is that I am suspecting that the policy will be large and possibly very dynamic, thus less suitable for locating in DNS. Also, instead of pointing directly to a single policy document, which seems like a one-size-fits-all periodic user poll option,; rather, use Subscriptions where the resulting document may depend on authentication and who is asking, and can be pushed on the schedule of the server when the policy changes. These are just suggestions being thrown out for discussion. I'd like to hear what folks think about them. I'm also questioning how much information about SIP needs to be embedded in other protocols like DNS, DHCP, etc. and how much might be more cohesive if handled via SIP-based mechanisms. Finding the right balance, if you will. Mike > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Wednesday, May 24, 2006 7:44 AM > To: Michael Hammer (mhammer) > Cc: speermint@ietf.org; Khan, Sohel Q [CTO] > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > Michael, > > On 2006/05/24 02:05, "Michael Hammer (mhammer)" > wrote: > > > > I did read one of your drafts, but had doubts about whether > all this > > policy data should be pushed in the DNS. > > Well, if the policy is to big, then the DNS can contain a URL > which points to the large policy. See the last example in > draft-lendl-domain-policy-ddds. > > > I was wondering whether the DNS could be used to discover: > > - that a particular user is served by a particular service > provider, > > Is the user identified by E.164 number or by SIP URI? > > If the latter, then my draft says: > > * either the domain part of the SIP URI is the provider's ID, or > > * a non-terminal NAPTR in the customer's domain points to the > provider's domain where the real policy is stored. > > (if the former, then ENUM is used first) > > > and > > - that service provider has a URI to which the originating SP can > > subscribe to get further information, and > > That fits in nicely with my draft. You just need to define a > policy-type for this subscription information. > > > - that information says the terminating SP can support peering with > > = federation subset A, or > > = federation subset B, or ... > > Ok; if this list is long, then an external document is fine. > If it is very short, I prefer storing it in the DNS and skip > one step at call setup time. > > If these are just named subsets, then the DNS need only store > the name of the subset and not the list of RFC and BCPs. > > > I suppose that policy document could list all the RFCs you > support and > > then spend time figuring out what matches and what doesn't. But I > > would wonder how well each permutation has been tested. > > That problem is independent of whether you store the > requirement list in the DNS or retrieve it via different means. > > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 24 11:02:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiurm-00021u-No; Wed, 24 May 2006 11:01:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiurl-00021n-LU for speermint@ietf.org; Wed, 24 May 2006 11:01:41 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fiurj-0003WI-8o for speermint@ietf.org; Wed, 24 May 2006 11:01:41 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 24 May 2006 08:01:39 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,167,1146466800"; d="scan'208"; a="28816265:sNHT25325028" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4OF1avF026716; Wed, 24 May 2006 11:01:36 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 May 2006 11:01:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 May 2006 11:01:35 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3017E65CE@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SPEERMINT Peering Architecture - LF - OF - SF Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAATumxgAG4BNwABEZoVAADcio0A== From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , "Brian Rosen" , "Francois D. Menard" , "Khan, Sohel Q [CTO]" , "David Meyer" , X-OriginalArrivalTime: 24 May 2006 15:01:36.0039 (UTC) FILETIME=[F3BBFB70:01C67F42] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: Subject: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hey, it worked for Socrates. :) While not adverse to calling it a PF versus OF, I am not certain that policy is all that is there, or whether to sort the other stuff out into other bins. I was hoping to do some grouping over the list provided by Bob Natale in: draft-natale-sip-voip-requirements-00.txt but haven't gotten to that yet. Mike > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Wednesday, May 24, 2006 4:37 AM > To: Michael Hammer (mhammer); Brian Rosen; Francois D.=20 > Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > Subject: RE: SPEERMINT Peering Architecture - LF - OF - SF >=20 > Michael, > >=20 > > Let me turn this around to you. >=20 > Good policy, answering a questing with another question ;-) > >=20 > > How much policy data do you stuff into ENUM? >=20 > None, the basic idea of Infrastructure ENUM (which will be=20 > used for service providers is to provide a domain name in a=20 > SIP URI =3D a service provider ID (SPID) >=20 > >=20 > > How general a database do you expect DNS to become? >=20 > Good question. The DNS is reliable, scalable and fast and it=20 > is available. So IMHO if some information is needed in some=20 > kind of database, DNS is the first choice (public and/or private DNS) >=20 > >=20 > > Do you expect that all peers will be pointed to the same=20 > entry point=20 > > into the network? >=20 > I assume with network you mean the destination "network"? > The answer is no, > =20 > > The thought was that before you blast the SF with INVITEs,=20 > it might be=20 > > useful to learn something about the nature of the interface=20 > > expectations. >=20 > Agreed, >=20 > I would suggest to rename OF to PF (Policy detection=20 > Function) IMHO the short description is ok Operation Function=20 > (OF): Purpose is to enable discovery and > > > exchange of policy and parameters to be used in with the SF > > > peering point. >=20 > the long description mentioning CALEA and Accounting is a bit=20 > misleading an needs rewording. Especially the negotiation of=20 > application servers is a bit early at this time. >=20 >=20 > >For the most part these are bins into which things can be organized=20 > >while this group gets started. If later it is concluded a > bin > > isn't needed, then it can be removed and whatever was collected > handled > > by some other bin. >=20 > Ok >=20 > Richard > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Tuesday, May 23, 2006 5:09 PM > > > To: Michael Hammer (mhammer); Brian Rosen; Francois D. > > > Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > > > Subject: SPEERMINT Peering Architecture - LF - OF - SF > > > > > > Folks, > > > > > > One general statement in advance: > > > Coming from the VON Europe last week with discussions=20 > about walled=20 > > > garden and IMS, my overall expression is that this draft=20 > in IMS in=20 > > > text-mode. > > > > > > I have another question for clarification to this draft,=20 > because I=20 > > > am confused: > > > > > > I do not understand that the LF is discovering the OF > > > > > > o Location Function (LF): Purpose is to enable=20 > discovery of the=20 > > > OF > > > peering point. > > > > > > o Operation Function (OF): Purpose is to enable discovery and > > > exchange of policy and parameters to be used in with the SF > > > peering point. > > > > > > o Signaling Function (SF): Purpose is to enable the discovery > of > > > endpoints and assist in discovery and exchange of=20 > parameters=20 > > > to be > > > used with the MF peering point. > > > > > > I always had the naive idea (also triggered by the SPEERMINT=20 > > > chartert that e.g. ENUM is a LF and discovering the SIP=20 > URIs uses in=20 > > > the SF > > > > > > How is now OF coming in between thsi, especially what is=20 > listed in=20 > > > the draft, especially CALEA, Accounting and Applications? > > > > > > "Operational data mediation: TBD > > > > > > o CALEA implementation: TBD > > > > > > o Accounting: Call Detail Record's (CDR's) MAY be=20 > collected to=20 > > > be > > > utilized by the peering operators. Based on the=20 > application,=20 > > > the > > > format should be an open standard for common consumption of > > > billing systems. Operators may use this data for a=20 > number of > > > reasons, including billing in the event the peering=20 > > > relationship > > > becomes asymmetric (unbalanced traffic flow) or there is a=20 > > > Tier 1 > > > to Tier 2 relationship. In order to limit the potential for > > > billing systems to impact the OF, a separate server=20 > should be > > > created to maintain all records collected from a single > > > interconnection to any number of OF's. > > > An OF can also be a special function that contains=20 > bi-laterally > > > disclosed information about the application servers=20 > and databases=20 > > > of > > > each IP service provider. An example of this function=20 > is to allow=20 > > > a > > > session to select a better suited application server from a set > of > > > application servers located inside both service providers' > > > network. " > > > > > > Richard > > > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 24 11:17:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiv6h-00088J-4H; Wed, 24 May 2006 11:17:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiv6g-00085s-J2 for speermint@ietf.org; Wed, 24 May 2006 11:17:06 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fiv6e-0004H2-4I for speermint@ietf.org; Wed, 24 May 2006 11:17:06 -0400 Received: from PMelampy [10.0.200.157] by acmepacket.com with ESMTP (SMTPD-9.03) id A8EB0444; Wed, 24 May 2006 11:16:59 -0400 From: "Patrick Melampy" To: "'Michael Hammer \(mhammer\)'" , "'Otmar Lendl'" Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Wed, 24 May 2006 11:17:01 -0400 Message-ID: <019c01c67f45$1b30ece0$0202fea9@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ/J15wu/Ba/2sNTLCXUP/3hHYAhQAFEQbgAAI7HVA= In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3017E6597@xmb-rtp-20b.amer.cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: "'Khan, Sohel Q \[CTO\]'" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Subscriptions have other beneficial attributes -- as they can work across network boundaries and have context. Subscribe/Notify can deliver a policy that corresponds to a reverse flow of SIP traffic. Plus the Notification can provide near real time changes. Also very contextual data can be included in the notification -- providing a nice mechanism for automatic congestion control. I like DNS providing LOCATION only, and I like the notion of all other attributes that have a contextual base to be delivered in a contextual way. Plus the actually XML policy document could be the same as your proposing -- but have additional information that is related to the exact subscription (proxy to proxy) relationship. -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Wednesday, May 24, 2006 10:22 AM To: Otmar Lendl Cc: Khan, Sohel Q [CTO]; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Otmar, I think our main difference is that I am suspecting that the policy will be large and possibly very dynamic, thus less suitable for locating in DNS. Also, instead of pointing directly to a single policy document, which seems like a one-size-fits-all periodic user poll option,; rather, use Subscriptions where the resulting document may depend on authentication and who is asking, and can be pushed on the schedule of the server when the policy changes. These are just suggestions being thrown out for discussion. I'd like to hear what folks think about them. I'm also questioning how much information about SIP needs to be embedded in other protocols like DNS, DHCP, etc. and how much might be more cohesive if handled via SIP-based mechanisms. Finding the right balance, if you will. Mike > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Wednesday, May 24, 2006 7:44 AM > To: Michael Hammer (mhammer) > Cc: speermint@ietf.org; Khan, Sohel Q [CTO] > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > Michael, > > On 2006/05/24 02:05, "Michael Hammer (mhammer)" > wrote: > > > > I did read one of your drafts, but had doubts about whether > all this > > policy data should be pushed in the DNS. > > Well, if the policy is to big, then the DNS can contain a URL > which points to the large policy. See the last example in > draft-lendl-domain-policy-ddds. > > > I was wondering whether the DNS could be used to discover: > > - that a particular user is served by a particular service > provider, > > Is the user identified by E.164 number or by SIP URI? > > If the latter, then my draft says: > > * either the domain part of the SIP URI is the provider's ID, or > > * a non-terminal NAPTR in the customer's domain points to the > provider's domain where the real policy is stored. > > (if the former, then ENUM is used first) > > > and > > - that service provider has a URI to which the originating SP can > > subscribe to get further information, and > > That fits in nicely with my draft. You just need to define a > policy-type for this subscription information. > > > - that information says the terminating SP can support peering with > > = federation subset A, or > > = federation subset B, or ... > > Ok; if this list is long, then an external document is fine. > If it is very short, I prefer storing it in the DNS and skip > one step at call setup time. > > If these are just named subsets, then the DNS need only store > the name of the subset and not the list of RFC and BCPs. > > > I suppose that policy document could list all the RFCs you > support and > > then spend time figuring out what matches and what doesn't. But I > > would wonder how well each permutation has been tested. > > That problem is independent of whether you store the > requirement list in the DNS or retrieve it via different means. > > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 24 12:12:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FivyA-0006DK-T8; Wed, 24 May 2006 12:12:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fivy8-0006D4-Ud for speermint@ietf.org; Wed, 24 May 2006 12:12:21 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fivy7-00076e-Ed for speermint@ietf.org; Wed, 24 May 2006 12:12:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF Date: Wed, 24 May 2006 18:16:20 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A65@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAATumxgAG4BNwABEZoVAADQ2DIAAC1z/9 From: "Stastny Richard" To: , "Michael Hammer \(mhammer\)" , "Brian Rosen" , "Francois D. Menard" , "Khan, Sohel Q [CTO]" , "David Meyer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Tim, =20 >> ... the basic idea of Infrastructure ENUM (which will be used for = service >> providers is to provide a domain name in a SIP URI =3D a service = provider ID >(SPID) >At the risk of asking an off-topic question (realizing that ENUM is not >within scope for SPEERMINT), can I ask where the idea that = Infrastructure >ENUM queries return SPIDs, comes from? It is my intent to provide a = point >of interconnection to be used by the requesting entity to hand to me a = call >to the specified number. I do not intend that the only meaningful part = of >the URI returned from the ENUM query, be the domain name. =20 thank you for raising this important point. I tried to raise this some = time ago, but got no clear answer Currently there exist two lines of thought about the usage of = Infrastructure (and also Carrier ENUM in private trees) =20 1. Put in ENUM the ingress point(s) e.g. = sip:+43xxxx@sbc4711.provider.net 2. Put in ENUM the AoR only: e.g. sip:+43xxx@provider.net (provider.net is what I meant with SPID) =20 Most currently prefer option 1, especially in private ENUM trees. =20 IMHO this is the wrong approach: =20 There should be a clear separation (and it is in the charter) between = ENUM and SPEERMINT SPEERMINT peering MUST be able to work standalone and without ENUM. Option 1 assumes also that the user is entering ALWAYS an E.164 number = as identifier. =20 But what if he is entering an AoR? =20 SPEEMINT peering MUST be able to resolve this too so you need to find the ingress point independant of ENUM e.g. via RFC3263. =20 If this MUST be possible, why not enter in (any) ENUM just the AoR, if you must be able to resolve the AoR anyway? Otherwise you need to manage two mappings separate 1. the E.164 to ingress point 2. the AoR mapping to ingress point this is not a good idea This is the reason why I would prefer to enter in ENUM AoRs only the user part in ENUM is always the E.164 number (for privacy reasons) the domain part is the SPID, which is mapped later to find the=20 ingress point the calling user may then also use an alis AoR such as = sip:name@provider.net regards Richard ________________________________ Von: Tim Dwight [mailto:timothy.dwight@verizon.com] Gesendet: Mi 24.05.2006 16:46 An: Stastny Richard; 'Michael Hammer (mhammer)'; 'Brian Rosen'; = 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; = speermint@ietf.org Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - = SF Stastny, Richard said: > ... the basic idea of Infrastructure ENUM (which will be used for = service > providers is to provide a domain name in a SIP URI =3D a service = provider ID (SPID) At the risk of asking an off-topic question (realizing that ENUM is not within scope for SPEERMINT), can I ask where the idea that = Infrastructure ENUM queries return SPIDs, comes from? It is my intent to provide a = point of interconnection to be used by the requesting entity to hand to me a = call to the specified number. I do not intend that the only meaningful part = of the URI returned from the ENUM query, be the domain name. tim _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 24 14:18:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fixw2-0000QG-GI; Wed, 24 May 2006 14:18:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fixw1-0000QB-8q for speermint@ietf.org; Wed, 24 May 2006 14:18:17 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fixw0-0005cZ-1r for speermint@ietf.org; Wed, 24 May 2006 14:18:17 -0400 Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.20509667; Wed, 24 May 2006 14:17:54 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 May 2006 14:17:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Wed, 24 May 2006 14:17:54 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96515F31@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAAKguMAArsMpg From: "Livingood, Jason" To: "Brian Rosen" , "Michael Hammer \(mhammer\)" , "Francois D. Menard" , "Khan, Sohel Q [CTO]" , "David Meyer" , X-OriginalArrivalTime: 24 May 2006 18:17:54.0412 (UTC) FILETIME=[603112C0:01C67F5E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org =20 > I mostly agree, but you have to decide what is in the set of=20 > RFCs, and to me, that is what call features are supported. =20 > So, I don't want to see an argument that says "we have to=20 > implement RFC xxxx because I like the author". I want to say=20 > "because we agree such and such feature works across the=20 > peering point, we must implement RFCs x, y and z". That's a pretty good way of stating it. And we'll get there soon. But we have to go one step at a time. Expect a message from the chairs soon on next steps for the WG that should hopefully clear up next steps and how we'll answer these questions. Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 24 15:46:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FizIz-00038l-8N; Wed, 24 May 2006 15:46:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FizIy-00038b-Ab for speermint@ietf.org; Wed, 24 May 2006 15:46:04 -0400 Received: from mx.plaxo.com ([66.151.128.13] helo=mx09.plaxo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FizIx-0002xy-Gh for speermint@ietf.org; Wed, 24 May 2006 15:46:04 -0400 Received: from bes03.plaxo.com (bes03.plaxo.com [10.1.10.3]) by mx09.plaxo.com (Postfix) with QMQP id 1EE0F42027 for ; Wed, 24 May 2006 12:45:59 -0700 (PDT) Message-ID: <1148499959.6648.27050.sendUpdate@mx.plaxo.com> Date: 24 May 2006 19:45:59 -0000 From: "Richard Stastny" To: "Speermint" Precedence: bulk MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_-------==2037590524" X-Spam-Score: 0.9 (/) X-Scan-Signature: 578029c71870398e30dc7af6a1ae528d Subject: [Speermint] Your contact info X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Reply-To: Plaxo Contact Update for Richard Stastny List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --_-------==2037590524 Content-Type: multipart/alternative; boundary="_--=======14193592" --_--=======14193592 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Speermint, I'm updating my address book. Please take a moment to update me with your latest contact info. Click the following link to correct or confirm your information: https://www.plaxo.com/edit_contact_info?r=12885123448-124335828-9448212 Name: speermint Job Title: Company: Work E-mail: speermint@ietf.org Work Phone: Work Fax: Work Address Line 1: Work Address Line 2: Work City, State, Zip: Mobile Phone: Home E-mail: Home Phone: Home Fax: Home Address Line 1: Home Address Line 2: Home City, State, Zip: Birthday: P.S. I've included my Plaxo card below so that you have my current information. I've also attached a copy as a vCard. +----------------- | Richard Stastny | richard.stastny@oefeg.at | | OeFEG | Arsenal Objekt 24 | work: +4317978032 | fax: +4317978013 | mobile: +436644204100 | web: voipandenum.blogspot.com +------------------------------------- ____________________________________________________________ This message was sent to you by richard.stastny@oefeg.at via Plaxo. To opt out: https://www.plaxo.com/opt_out?r=12885123448-124335828-9448212 Plaxo's Privacy Policy: http://www.plaxo.com/support/privacy --_--=======14193592 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Your Contact Info
=20 =20 =20 =20

Speermint,

I'm updating= my address book. Please take a moment to update me with your latest cont= act info.

Thanks,
Richard Stastny

 

 =20 =20 =20
=20 =20 =20 =20 =20
=20 =20 =20 =20 =20 =20 =20
=20
=20 =20 =20
=09 speermint =20
no title
<= /td> =20 no company=
=09 no work address =09
=20 speermint@ietf.org
=20 =20 no web page
IM: none
 <= /td> =20 =20 <= td class=3D"table_small" nowrap align=3Dright>none none =20
tel: none
fax: none
mobile: 
pager: 
 
=20 =20 =20
=09 Personal Information =09
=09
=09 =09 no home address =09
=20 no email<= /span>
=20 =20 no web page
IM: none
 <= /td> =20 <= span id=3D"START.PlaxoField.Home.Phone1">none =20 <= td class=3D"table_small" nowrap align=3Dright>none =20 =20
home: 
fax: none
mobile: 
birthday: none
=20
     
 
=20
Click to update your info 3D"->"3D"Click
=20
=20


P.S.= I've attached my current information in a vcard. If you=20 get Plaxo too, we can= stay connected without the hassle of sending emails back and forth.
<= /P> =20

If you do = not wish to receive update request emails from Richard Stastny, click h= ere to opt-out.

--_--=======14193592-- --_-------==2037590524 Content-Type: text/x-vcard; charset=ISO-8859-1; name="Richard Stastny.vcf" Content-Disposition: attachment; filename="Richard Stastny.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD=20 VERSION:2.1 N:Stastny;Richard;;; FN:Richard Stastny ORG:OeFEG ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Arsenal Objekt 24;Vienna;;1103;Aus= tria TEL;WORK;VOICE:+4317978032 TEL;CELL;VOICE:+436644204100 TEL;WORK;FAX:+4317978013 EMAIL;PREF;INTERNET;WORK:richard.stastny@oefeg.at URL;WORK:http://voipandenum.blogspot.com END:VCARD --_-------==2037590524 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --_-------==2037590524-- From speermint-bounces@ietf.org Wed May 24 16:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fizuw-0002z7-VT; Wed, 24 May 2006 16:25:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fizuv-0002yT-EW for speermint@ietf.org; Wed, 24 May 2006 16:25:17 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fizuu-0005fz-5V for speermint@ietf.org; Wed, 24 May 2006 16:25:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Your contact info - sorry Date: Wed, 24 May 2006 22:28:32 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A6B@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Your contact info - sorry Thread-Index: AcZ/a1JYwJSD2EGXQfahBMGgN1x0TAABU20A From: "Stastny Richard" To: "Speermint" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 24 17:05:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj0XH-0003p7-Gj; Wed, 24 May 2006 17:04:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj0XG-0003kb-Hn for speermint@ietf.org; Wed, 24 May 2006 17:04:54 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj0XE-0000dY-2q for speermint@ietf.org; Wed, 24 May 2006 17:04:54 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 71FD11A3A4; Wed, 24 May 2006 23:04:39 +0200 (CEST) Date: Wed, 24 May 2006 23:04:39 +0200 From: Otmar Lendl To: "Michael Hammer (mhammer)" Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Message-ID: <20060524210439.GD1811@nic.at> Mail-Followup-To: Otmar Lendl , "Michael Hammer (mhammer)" , "Khan, Sohel Q [CTO]" , speermint@ietf.org References: <072C5B76F7CEAB488172C6F64B30B5E3017E6597@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3017E6597@xmb-rtp-20b.amer.cisco.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: "Khan, Sohel Q \[CTO\]" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Michael, On 2006/05/24 16:05, "Michael Hammer (mhammer)" wrote: > > I think our main difference is that I am suspecting that the policy will > be large and possibly very dynamic, thus less suitable for locating in > DNS. Also, instead of pointing directly to a single policy document, > which seems like a one-size-fits-all periodic user poll option,; rather, > use Subscriptions where the resulting document may depend on > authentication and who is asking, and can be pushed on the schedule of > the server when the policy changes. My guess is that the size of the policy will vary a great deal. We don't know yet what the market will establish in the future. That's why I used URIs are policy element identifiers. This gives us a wide range of options: * Simple IDs which refer to offline established policies. (= federation names) * References to standards * References to documents describing a complex policy and (if you want a dynamic protocol) * the location and connection parameters for any routing / policy-exchange / ... protocol. As an example (and not meant as a real proposal): let's assume that the destination requires the use of the Open Settlement Protocol. We could standardize an URI scheme for that, e.g. "osp://hostname:port/" and a suitable policy-record could thus be NAPTR 10 10 "u" "D2P+SIP:osp" "!.*!osp://hostname:port/! . You can do the same for your subscription model. ---- As for why you don't want to do all that with SIP, I refer to http://www1.ietf.org/mail-archive/web/speermint/current/msg00218.html > These are just suggestions being thrown out for discussion. I'd like to > hear what folks think about them. So do I. > I'm also questioning how much information about SIP needs to be embedded > in other protocols like DNS, DHCP, etc. and how much might be more > cohesive if handled via SIP-based mechanisms. Finding the right > balance, if you will. Indeed. My problem with a pure SIP solution is the following: Assuming that members of some federations will opt to move their SIP ingress points to private IP networks and/or firewall them heavily I see a severe chicken and egg problem if the discovery of the correct SIP ingress point is done by a SIP exchange. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 24 17:34:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj0ze-0002mz-30; Wed, 24 May 2006 17:34:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj0zc-0002mg-LW for speermint@ietf.org; Wed, 24 May 2006 17:34:12 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fj0zb-0002YN-RZ for speermint@ietf.org; Wed, 24 May 2006 17:34:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF Date: Wed, 24 May 2006 23:38:14 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A73@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAATumxgAG4BNwABEZoVAADQ2DIAAC1z/9AAGrFeAACZ2pfQ== From: "Stastny Richard" To: , , "Michael Hammer \(mhammer\)" , "Brian Rosen" , "Francois D. Menard" , "Khan, Sohel Q [CTO]" , "David Meyer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Tim, =20 thanx for your reply, you are raising some important issues.=20 Since it is already midnight here, I will reply to it in detail tomorrow =20 I am also working on a more detailed analysis and a draft which will require even some more time. =20 Just a quick one: =20 >In some parts of the world the function provided by "option 2" usage of >Infrastructure ENUM could be achieved in other ways (e.g., the LERG and = NPDB >in North America) so in those cases Infrastructure ENUM might be a >superfluous concept; but if that's the right technical answer so be = it. =20 Yes and no ;-) You are mixing up here the Registry and the ENUM DNS. The Registry is the LERG and NPDB (or is derived from), the ENUM DNS is the equivalent on IP of the SCP in the PSTN where the date is downloaded to. =20 Richard =20 ________________________________ Von: Tim Dwight [mailto:timothy.dwight@verizon.com] Gesendet: Mi 24.05.2006 23:00 An: Stastny Richard; timothy.dwight@verizon.com; 'Michael Hammer = (mhammer)'; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; = 'David Meyer'; speermint@ietf.org Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - = SF Richard, Thank you for the clarification. I understand the distinction you are making. My objective is to be able to translate a destination identifier (E.164 number of alphanumeric AoR) into the address of a Layer 5 entity = designated by the organization providing service to the called party. With infrastructure/carrier ENUM I could do this (as described in your Option = 1), but because ENUM is specific to E.164 numbers it would only work for = E.164 -formatted destination identifiers. In pictures, your Option 2 seems to me to imply the following: +----------------+ +----------+ E.164 | infrastructure | serving | identify | = network ingress destination -->| ENUM |---> carrier --->| ingress |---> point specified identifier | (option 2) | identity | point | by serving carrier +----------------+ ^ +----------+ | +----------------+ | non-E.164 | map domain in | | Destination -->| URI to carrier |--------+ Identifier | identity | +----------------+ In some parts of the world the function provided by "option 2" usage of Infrastructure ENUM could be achieved in other ways (e.g., the LERG and = NPDB in North America) so in those cases Infrastructure ENUM might be a superfluous concept; but if that's the right technical answer so be it. The "identify ingress point" function would need to be defined. I would like it to consider the specified destination (in addition to the = carrier providing service to that destination); and I would like the procedures = to be such that the serving carrier controls (in a reasonably dynamic way) = the point at which traffic destined to a particular destination, enters his network. If those requirements can be met, I think this approach is workable. Its biggest drawback is that it precludes a solution ("option 1" usage = of Infrastructure ENUM) that is sufficient for the majority of today's = needs. It optimizes for a problem that will exist in the future at the expense = of solving problems that exist today. I realize that solving today's = problems may not be SPEERMINT's focus, or (arguably) even within its charter, but = I would hate to see recommendations from SPEERMINT preclude or = significantly delay solving them. Suppose we did something like this: +----------+ [pseudo +----------------+ non-E.164 | identify | or real] | infrastructure | = network ingress destination -->| "pseudo" |---> E.164 --->| ENUM |---> point specified identifier | E.164 | number | (option 1) | by serving carrier +----------+ +----------------+ We could let the ENUM working group define Infrastructure ENUM as = described in your Option 1 (which is as you know already commercially available = from a few sources) and SPEERMINT could define the "identify pseudo E.164" = function that in my diagram feeds into it. This function might be as simple as mapping the domain part of the URI to an E.164 number uniquely = associated with the network providing service to the specified destination. Unless this is a lot harder than it seems, this shouldn't keep us busy too long = :-) Tim -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Wednesday, May 24, 2006 11:16 AM To: timothy.dwight@verizon.com; Michael Hammer (mhammer); Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - = SF Tim, >> ... the basic idea of Infrastructure ENUM (which will be used for >> service providers is to provide a domain name in a SIP URI =3D a >> service provider ID >(SPID) >At the risk of asking an off-topic question (realizing that ENUM is not >within scope for SPEERMINT), can I ask where the idea that >Infrastructure ENUM queries return SPIDs, comes from? It is my intent >to provide a point of interconnection to be used by the requesting >entity to hand to me a call to the specified number. I do not intend >that the only meaningful part of the URI returned from the ENUM query, = be the domain name. thank you for raising this important point. I tried to raise this some = time ago, but got no clear answer Currently there exist two lines of thought about the usage of = Infrastructure (and also Carrier ENUM in private trees) 1. Put in ENUM the ingress point(s) e.g. = sip:+43xxxx@sbc4711.provider.net 2. Put in ENUM the AoR only: e.g. sip:+43xxx@provider.net (provider.net is = what I meant with SPID) Most currently prefer option 1, especially in private ENUM trees. IMHO this is the wrong approach: There should be a clear separation (and it is in the charter) between = ENUM and SPEERMINT SPEERMINT peering MUST be able to work standalone and = without ENUM. Option 1 assumes also that the user is entering ALWAYS an E.164 number = as identifier. But what if he is entering an AoR? SPEEMINT peering MUST be able to resolve this too so you need to find = the ingress point independant of ENUM e.g. via RFC3263. If this MUST be possible, why not enter in (any) ENUM just the AoR, if = you must be able to resolve the AoR anyway? Otherwise you need to manage two mappings separate 1. the E.164 to = ingress point 2. the AoR mapping to ingress point this is not a good idea This is the reason why I would prefer to enter in ENUM AoRs only the = user part in ENUM is always the E.164 number (for privacy reasons) the domain part is the SPID, which is mapped later to find the ingress point the calling user may then also use an alis AoR such as = sip:name@provider.net regards Richard ________________________________ Von: Tim Dwight [mailto:timothy.dwight@verizon.com] Gesendet: Mi 24.05.2006 16:46 An: Stastny Richard; 'Michael Hammer (mhammer)'; 'Brian Rosen'; = 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; speermint@ietf.org Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - = SF Stastny, Richard said: > ... the basic idea of Infrastructure ENUM (which will be used for > service providers is to provide a domain name in a SIP URI =3D a = service > provider ID (SPID) At the risk of asking an off-topic question (realizing that ENUM is not within scope for SPEERMINT), can I ask where the idea that = Infrastructure ENUM queries return SPIDs, comes from? It is my intent to provide a = point of interconnection to be used by the requesting entity to hand to me a = call to the specified number. I do not intend that the only meaningful part = of the URI returned from the ENUM query, be the domain name. tim _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 24 18:44:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj251-000143-Lw; Wed, 24 May 2006 18:43:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj251-00013y-4O for speermint@ietf.org; Wed, 24 May 2006 18:43:51 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fj24y-0006lu-0K for speermint@ietf.org; Wed, 24 May 2006 18:43:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF Date: Thu, 25 May 2006 00:44:26 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A74@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAATumxgAG4BNwABEZoVAADQ2DIAAC1z/9AAGrFeAACZ2pfQABju7wAAFXgQM= From: "Stastny Richard" To: , , , "Michael Hammer \(mhammer\)" , "Brian Rosen" , "Francois D. Menard" , "Khan, Sohel Q [CTO]" , "David Meyer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Tim, =20 another short reply: b) you can provide a LRN, with the pstn Enumservice and if you can explain to me how a plain sip-proxy accesses=20 e.g the OpenSER accesses the LERG and the LNP database especially from e.g. Austria, fine With Infrastructure ENUM this is a no-brainer =20 Richard ________________________________ Von: Tim Dwight [mailto:timothy.dwight@verizon.com] Gesendet: Do 25.05.2006 00:19 An: Stastny Richard; timothy.dwight@verizon.com; = timothy.dwight@verizon.com; 'Michael Hammer (mhammer)'; 'Brian Rosen'; = 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; = speermint@ietf.org Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - = SF Richard, Yes I know I was mixing data and mechanism-to-access-data. Still I = believe the major point to be correct. In many parts of the world there are = already mechanisms (associated with Local Number Portability) to determine = ownership of an E.164 number, hence use of ENUM for this purpose alone, will be unnecessary.=20 To be clear, I believe that providing access via Infrastructure ENUM to = LNP information may be very helpful; but only if Infrastructure ENUM = provides more than just this. If an Infrastructure ENUM query can combine (a) determination of the entity providing service to the destination, (b) determination of the corresponding LRN, if one exists, and (c) mapping = of the routable number (either the number originally indicated, or the LRN) = to a Layer 5 "point of ingress" specified by the entity providing service = to the destination; then Infrastructure ENUM is quite a handy mechanism. = If all it does is (a) then I don't need it. But in the end this is neither here nor there. I am not wedded to any specific technology, I just need workable solutions to real business problems. Tim -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Wednesday, May 24, 2006 4:38 PM To: timothy.dwight@verizon.com; timothy.dwight@verizon.com; Michael = Hammer (mhammer); Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - = SF Tim, thanx for your reply, you are raising some important issues. Since it is already midnight here, I will reply to it in detail tomorrow I am also working on a more detailed analysis and a draft which will = require even some more time. Just a quick one: >In some parts of the world the function provided by "option 2" usage of >Infrastructure ENUM could be achieved in other ways (e.g., the LERG and >NPDB in North America) so in those cases Infrastructure ENUM might be a >superfluous concept; but if that's the right technical answer so be = it. Yes and no ;-) You are mixing up here the Registry and the ENUM DNS. The Registry is the LERG and NPDB (or is derived from), the ENUM DNS is = the equivalent on IP of the SCP in the PSTN where the date is downloaded to. Richard ________________________________ Von: Tim Dwight [mailto:timothy.dwight@verizon.com] Gesendet: Mi 24.05.2006 23:00 An: Stastny Richard; timothy.dwight@verizon.com; 'Michael Hammer = (mhammer)'; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David = Meyer'; speermint@ietf.org Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - = SF Richard, Thank you for the clarification. I understand the distinction you are making. My objective is to be able to translate a destination identifier (E.164 number of alphanumeric AoR) into the address of a Layer 5 entity = designated by the organization providing service to the called party. With infrastructure/carrier ENUM I could do this (as described in your Option = 1), but because ENUM is specific to E.164 numbers it would only work for = E.164 -formatted destination identifiers. In pictures, your Option 2 seems to me to imply the following: +----------------+ +----------+ E.164 | infrastructure | serving | identify | = network ingress destination -->| ENUM |---> carrier --->| ingress |---> point specified identifier | (option 2) | identity | point | by serving carrier +----------------+ ^ +----------+ | +----------------+ | non-E.164 | map domain in | | Destination -->| URI to carrier |--------+ Identifier | identity | +----------------+ In some parts of the world the function provided by "option 2" usage of Infrastructure ENUM could be achieved in other ways (e.g., the LERG and = NPDB in North America) so in those cases Infrastructure ENUM might be a superfluous concept; but if that's the right technical answer so be it. The "identify ingress point" function would need to be defined. I would like it to consider the specified destination (in addition to the = carrier providing service to that destination); and I would like the procedures = to be such that the serving carrier controls (in a reasonably dynamic way) = the point at which traffic destined to a particular destination, enters his network. If those requirements can be met, I think this approach is workable. Its biggest drawback is that it precludes a solution ("option 1" usage = of Infrastructure ENUM) that is sufficient for the majority of today's = needs. It optimizes for a problem that will exist in the future at the expense = of solving problems that exist today. I realize that solving today's = problems may not be SPEERMINT's focus, or (arguably) even within its charter, but = I would hate to see recommendations from SPEERMINT preclude or = significantly delay solving them. Suppose we did something like this: +----------+ [pseudo +----------------+ non-E.164 | identify | or real] | infrastructure | = network ingress destination -->| "pseudo" |---> E.164 --->| ENUM |---> point specified identifier | E.164 | number | (option 1) | by serving carrier +----------+ +----------------+ We could let the ENUM working group define Infrastructure ENUM as = described in your Option 1 (which is as you know already commercially available = from a few sources) and SPEERMINT could define the "identify pseudo E.164" = function that in my diagram feeds into it. This function might be as simple as mapping the domain part of the URI to an E.164 number uniquely = associated with the network providing service to the specified destination. Unless this is a lot harder than it seems, this shouldn't keep us busy too long = :-) Tim -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Wednesday, May 24, 2006 11:16 AM To: timothy.dwight@verizon.com; Michael Hammer (mhammer); Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - = SF Tim, >> ... the basic idea of Infrastructure ENUM (which will be used for >> service providers is to provide a domain name in a SIP URI =3D a >> service provider ID >(SPID) >At the risk of asking an off-topic question (realizing that ENUM is not >within scope for SPEERMINT), can I ask where the idea that >Infrastructure ENUM queries return SPIDs, comes from? It is my intent >to provide a point of interconnection to be used by the requesting >entity to hand to me a call to the specified number. I do not intend >that the only meaningful part of the URI returned from the ENUM query, >be the domain name. thank you for raising this important point. I tried to raise this some = time ago, but got no clear answer Currently there exist two lines of thought about the usage of = Infrastructure (and also Carrier ENUM in private trees) 1. Put in ENUM the ingress point(s) e.g. = sip:+43xxxx@sbc4711.provider.net 2. Put in ENUM the AoR only: e.g. sip:+43xxx@provider.net (provider.net is = what I meant with SPID) Most currently prefer option 1, especially in private ENUM trees. IMHO this is the wrong approach: There should be a clear separation (and it is in the charter) between = ENUM and SPEERMINT SPEERMINT peering MUST be able to work standalone and = without ENUM. Option 1 assumes also that the user is entering ALWAYS an E.164 number = as identifier. But what if he is entering an AoR? SPEEMINT peering MUST be able to resolve this too so you need to find = the ingress point independant of ENUM e.g. via RFC3263. If this MUST be possible, why not enter in (any) ENUM just the AoR, if = you must be able to resolve the AoR anyway? Otherwise you need to manage two mappings separate 1. the E.164 to = ingress point 2. the AoR mapping to ingress point this is not a good idea This is the reason why I would prefer to enter in ENUM AoRs only the = user part in ENUM is always the E.164 number (for privacy reasons) the domain part is the SPID, which is mapped later to find the ingress point the calling user may then also use an alis AoR such as = sip:name@provider.net regards Richard ________________________________ Von: Tim Dwight [mailto:timothy.dwight@verizon.com] Gesendet: Mi 24.05.2006 16:46 An: Stastny Richard; 'Michael Hammer (mhammer)'; 'Brian Rosen'; = 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; speermint@ietf.org Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - = SF Stastny, Richard said: > ... the basic idea of Infrastructure ENUM (which will be used for > service providers is to provide a domain name in a SIP URI =3D a = service > provider ID (SPID) At the risk of asking an off-topic question (realizing that ENUM is not within scope for SPEERMINT), can I ask where the idea that = Infrastructure ENUM queries return SPIDs, comes from? It is my intent to provide a = point of interconnection to be used by the requesting entity to hand to me a = call to the specified number. I do not intend that the only meaningful part = of the URI returned from the ENUM query, be the domain name. tim _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu May 25 10:27:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjGns-0004jg-6w; Thu, 25 May 2006 10:27:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjGnq-0004jY-Tl for speermint@ietf.org; Thu, 25 May 2006 10:27:06 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjGnq-0005RW-Qf for speermint@ietf.org; Thu, 25 May 2006 10:27:06 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FjGmX-0000iy-Qj for speermint@ietf.org; Thu, 25 May 2006 10:25:48 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 25 May 2006 07:25:44 -0700 X-IronPort-AV: i="4.05,173,1146466800"; d="scan'208"; a="1812707598:sNHT68186586" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k4PEPin9029701; Thu, 25 May 2006 07:25:44 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4PEPKBf019534; Thu, 25 May 2006 07:25:36 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 May 2006 10:25:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF Date: Thu, 25 May 2006 10:25:31 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301847D15@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAATumxgAG4BNwABEZoVAADQ2DIAAC1z/9AAGrFeAACZ2pfQABju7wACHfcEA= From: "Michael Hammer \(mhammer\)" To: , "Stastny Richard" , "Brian Rosen" , "Francois D. Menard" , "Khan, Sohel Q [CTO]" , "David Meyer" , X-OriginalArrivalTime: 25 May 2006 14:25:32.0080 (UTC) FILETIME=[1453CB00:01C68007] DKIM-Signature: a=rsa-sha1; q=dns; l=12163; t=1148567144; x=1149431144; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20RE=3A=20SPEERMINT=20Peering=20Architecture=20-=20L F=20-=20OF=20-=20SF; X=v=3Dcisco.com=3B=20h=3DBzWVOzi7eMX+BufjHgZDTf9wqDY=3D; b=FoggXgQSPMGe65QTrjsBFyBBj2/3o9UfCgq/PjkxPpT6yfNbxMbMJLjf3LSXnb8plq6jl3Jk 9J1bHXhOzrW7NZoVu0k3R14TntY47ZXCys4k8nVvkP9tUieQedEf2VD3; Authentication-Results: sj-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Tim, The LERG and LNP databases are intrinsically tied to the operation of the TDM infrastructure. Any design that perpatuates these systems when their reason for being (TDM) goes away is a faulty design. DNS and ENUM provides the equivalent information and mechanisms to do what is needed in the IP domain. As such, a design that makes dependencies on legacy systems is deficient. I wouldn't support such a kludge. That said, if there are backward compatibilities during the transition, where some information just happens to be known by external systems, such as you suggest below, I don't see that as a problem. I am just wary of ending up with two systems in the end when one would do. Mike > -----Original Message----- > From: Tim Dwight [mailto:timothy.dwight@verizon.com]=20 > Sent: Wednesday, May 24, 2006 6:19 PM > To: 'Stastny Richard'; timothy.dwight@verizon.com;=20 > timothy.dwight@verizon.com; Michael Hammer (mhammer); 'Brian=20 > Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David=20 > Meyer'; speermint@ietf.org > Subject: RE: [Speermint] RE: SPEERMINT Peering Architecture -=20 > LF - OF - SF >=20 > Richard, >=20 > Yes I know I was mixing data and mechanism-to-access-data. =20 > Still I believe the major point to be correct. In many parts=20 > of the world there are already mechanisms (associated with=20 > Local Number Portability) to determine ownership of an E.164=20 > number, hence use of ENUM for this purpose alone, will be=20 > unnecessary. =20 >=20 > To be clear, I believe that providing access via=20 > Infrastructure ENUM to LNP information may be very helpful; =20 > but only if Infrastructure ENUM provides more than just this.=20 > If an Infrastructure ENUM query can combine (a)=20 > determination of the entity providing service to the=20 > destination, (b) determination of the corresponding LRN, if=20 > one exists, and (c) mapping of the routable number (either=20 > the number originally indicated, or the LRN) to a Layer 5=20 > "point of ingress" specified by the entity providing service=20 > to the destination; then Infrastructure ENUM is quite a=20 > handy mechanism. If all it does is (a) then I don't need it. >=20 > But in the end this is neither here nor there. I am not=20 > wedded to any specific technology, I just need workable=20 > solutions to real business problems. >=20 > Tim >=20 >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, May 24, 2006 4:38 PM > To: timothy.dwight@verizon.com; timothy.dwight@verizon.com;=20 > Michael Hammer (mhammer); Brian Rosen; Francois D. Menard;=20 > Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture -=20 > LF - OF - SF >=20 > Tim, > =20 > thanx for your reply, you are raising some important issues.=20 > Since it is already midnight here, I will reply to it in=20 > detail tomorrow > =20 > I am also working on a more detailed analysis and a draft=20 > which will require even some more time. > =20 > Just a quick one: > =20 > >In some parts of the world the function provided by "option=20 > 2" usage of=20 > >Infrastructure ENUM could be achieved in other ways (e.g.,=20 > the LERG and=20 > >NPDB in North America) so in those cases Infrastructure ENUM=20 > might be a=20 > >superfluous concept; but if that's the right technical=20 > answer so be it. > =20 > Yes and no ;-) > You are mixing up here the Registry and the ENUM DNS. > The Registry is the LERG and NPDB (or is derived from), the=20 > ENUM DNS is the equivalent on IP of the SCP in the PSTN where=20 > the date is downloaded to. > =20 > Richard > =20 >=20 > ________________________________ >=20 > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > Gesendet: Mi 24.05.2006 23:00 > An: Stastny Richard; timothy.dwight@verizon.com; 'Michael=20 > Hammer (mhammer)'; 'Brian Rosen'; 'Francois D. Menard';=20 > 'Khan, Sohel Q [CTO]'; 'David Meyer'; speermint@ietf.org > Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture -=20 > LF - OF - SF >=20 >=20 >=20 > Richard, >=20 > Thank you for the clarification. I understand the=20 > distinction you are making. >=20 > My objective is to be able to translate a destination=20 > identifier (E.164 number of alphanumeric AoR) into the=20 > address of a Layer 5 entity designated by the organization=20 > providing service to the called party. With=20 > infrastructure/carrier ENUM I could do this (as described in=20 > your Option 1), but because ENUM is specific to E.164 numbers=20 > it would only work for E.164 -formatted destination identifiers. >=20 > In pictures, your Option 2 seems to me to imply the following: >=20 > +----------------+ +----------+ > E.164 | infrastructure | serving | identify=20 > | network > ingress > destination -->| ENUM |---> carrier --->| ingress =20 > |---> point > specified > identifier | (option 2) | identity | point | by > serving carrier > +----------------+ ^ +----------+ > | > +----------------+ | > non-E.164 | map domain in | | > Destination -->| URI to carrier |--------+ > Identifier | identity | > +----------------+ >=20 > In some parts of the world the function provided by "option=20 > 2" usage of Infrastructure ENUM could be achieved in other=20 > ways (e.g., the LERG and NPDB in North America) so in those=20 > cases Infrastructure ENUM might be a superfluous concept; =20 > but if that's the right technical answer so be it. >=20 > The "identify ingress point" function would need to be=20 > defined. I would like it to consider the specified=20 > destination (in addition to the carrier providing service to=20 > that destination); and I would like the procedures to be such=20 > that the serving carrier controls (in a reasonably dynamic=20 > way) the point at which traffic destined to a particular=20 > destination, enters his network. If those requirements can=20 > be met, I think this approach is workable. >=20 > Its biggest drawback is that it precludes a solution ("option=20 > 1" usage of Infrastructure ENUM) that is sufficient for the=20 > majority of today's needs. > It optimizes for a problem that will exist in the future at=20 > the expense of solving problems that exist today. I realize=20 > that solving today's problems may not be SPEERMINT's focus,=20 > or (arguably) even within its charter, but I would hate to=20 > see recommendations from SPEERMINT preclude or significantly=20 > delay solving them. >=20 > Suppose we did something like this: >=20 > +----------+ [pseudo +----------------+ > non-E.164 | identify | or real] | infrastructure=20 > | network > ingress > destination -->| "pseudo" |---> E.164 --->| ENUM =20 > |---> point > specified > identifier | E.164 | number | (option 1) | by > serving carrier > +----------+ +----------------+ >=20 > We could let the ENUM working group define Infrastructure=20 > ENUM as described in your Option 1 (which is as you know=20 > already commercially available from a few sources) and=20 > SPEERMINT could define the "identify pseudo E.164" function=20 > that in my diagram feeds into it. This function might be as=20 > simple as mapping the domain part of the URI to an E.164=20 > number uniquely associated with the network providing service=20 > to the specified destination. Unless this is a lot harder=20 > than it seems, this shouldn't keep us busy too long :-) >=20 >=20 > Tim >=20 >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, May 24, 2006 11:16 AM > To: timothy.dwight@verizon.com; Michael Hammer (mhammer);=20 > Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David=20 > Meyer; speermint@ietf.org > Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture -=20 > LF - OF - SF >=20 > Tim, >=20 > >> ... the basic idea of Infrastructure ENUM (which will be used for=20 > >> service providers is to provide a domain name in a SIP URI =3D a=20 > >> service provider ID > >(SPID) >=20 > >At the risk of asking an off-topic question (realizing that=20 > ENUM is not=20 > >within scope for SPEERMINT), can I ask where the idea that=20 > >Infrastructure ENUM queries return SPIDs, comes from? It is=20 > my intent=20 > >to provide a point of interconnection to be used by the requesting=20 > >entity to hand to me a call to the specified number. I do=20 > not intend=20 > >that the only meaningful part of the URI returned from the=20 > ENUM query,=20 > >be > the domain name. >=20 > thank you for raising this important point. I tried to raise=20 > this some time ago, but got no clear answer >=20 > Currently there exist two lines of thought about the usage of=20 > Infrastructure (and also Carrier ENUM in private trees) >=20 > 1. Put in ENUM the ingress point(s) e.g.=20 > sip:+43xxxx@sbc4711.provider.net 2. > Put in ENUM the AoR only: e.g. sip:+43xxx@provider.net=20 > (provider.net is what I meant with SPID) >=20 > Most currently prefer option 1, especially in private ENUM trees. >=20 > IMHO this is the wrong approach: >=20 > There should be a clear separation (and it is in the charter)=20 > between ENUM and SPEERMINT SPEERMINT peering MUST be able to=20 > work standalone and without ENUM. >=20 > Option 1 assumes also that the user is entering ALWAYS an=20 > E.164 number as identifier. >=20 > But what if he is entering an AoR? >=20 > SPEEMINT peering MUST be able to resolve this too so you need=20 > to find the ingress point independant of ENUM e.g. via RFC3263. >=20 > If this MUST be possible, why not enter in (any) ENUM just=20 > the AoR, if you must be able to resolve the AoR anyway? >=20 > Otherwise you need to manage two mappings separate 1. the=20 > E.164 to ingress point 2. the AoR mapping to ingress point >=20 > this is not a good idea >=20 > This is the reason why I would prefer to enter in ENUM AoRs=20 > only the user part in ENUM is always the E.164 number (for=20 > privacy reasons) the domain part is the SPID, which is mapped=20 > later to find the ingress point >=20 > the calling user may then also use an alis AoR such as=20 > sip:name@provider.net >=20 > regards >=20 > Richard >=20 >=20 >=20 > ________________________________ >=20 > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > Gesendet: Mi 24.05.2006 16:46 > An: Stastny Richard; 'Michael Hammer (mhammer)'; 'Brian=20 > Rosen'; 'Francois D. > Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; speermint@ietf.org > Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture -=20 > LF - OF - SF >=20 >=20 >=20 > Stastny, Richard said: >=20 > > ... the basic idea of Infrastructure ENUM (which will be used for=20 > > service providers is to provide a domain name in a SIP URI=20 > =3D a service=20 > > provider ID > (SPID) >=20 > At the risk of asking an off-topic question (realizing that=20 > ENUM is not within scope for SPEERMINT), can I ask where the=20 > idea that Infrastructure ENUM queries return SPIDs, comes=20 > from? It is my intent to provide a point of interconnection=20 > to be used by the requesting entity to hand to me a call to=20 > the specified number. I do not intend that the only=20 > meaningful part of the URI returned from the ENUM query, be=20 > the domain name. >=20 > tim >=20 >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu May 25 10:48:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjH7n-0007Ys-Dc; Thu, 25 May 2006 10:47:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjH7m-0007Yi-67 for speermint@ietf.org; Thu, 25 May 2006 10:47:42 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjH7k-0007pc-QZ for speermint@ietf.org; Thu, 25 May 2006 10:47:42 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k4PElMGN014038; Thu, 25 May 2006 07:47:22 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k4PElMZp014037; Thu, 25 May 2006 07:47:22 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 25 May 2006 07:47:22 -0700 From: David Meyer To: Andrew Newton Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Message-ID: <20060525144722.GA14022@1-4-5.net> References: <09d001c67e9b$bb2850d0$640fa8c0@cis.neustar.com> <4473737E.5090101@hxr.us> Mime-Version: 1.0 In-Reply-To: <4473737E.5090101@hxr.us> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: speermint@ietf.org, "'Khan, Sohel Q \[CTO\]'" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0400846028==" Errors-To: speermint-bounces@ietf.org --===============0400846028== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 23, 2006 at 04:41:34PM -0400, Andrew Newton wrote: > Brian Rosen wrote: > >By far the largest mistake EVER made by the IETF in the development of S= IP > >was to allow SIP to be extended to imitate the existing PSTN. If we ever > >were to start again, the golden rule would be DON'T IMITATE THE PSTN, and > >the corollary would be "Just because the PSTN does it that way DOES NOT= =20 > >MEAN > >it's a good idea". > > > >So, the very idea that "replication of functionality in the SS7 minimum > >message set" is the definition of what we need to do makes me want to pu= ke. >=20 > I agree totally with Brian. We should not try to replicate the PSTN=20 > over IP. FWIW, that's an explict non-goal for speermint. --dmm --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEdcN6ORgD1qCZ2KcRAkS3AJ4kHwq8B9Gw6oOZFu8uQmdlzjwRNQCfZv4C QQRL9AV+dzrvxsbHF6ee76Q= =gNBk -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V-- --===============0400846028== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0400846028==-- From speermint-bounces@ietf.org Thu May 25 10:53:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjHDB-0001uu-Pu; Thu, 25 May 2006 10:53:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjHDA-0001up-28 for speermint@ietf.org; Thu, 25 May 2006 10:53:16 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjHD8-0008Mi-Mm for speermint@ietf.org; Thu, 25 May 2006 10:53:16 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k4PErD1o014120; Thu, 25 May 2006 07:53:13 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k4PEr99p014117; Thu, 25 May 2006 07:53:09 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 25 May 2006 07:53:09 -0700 From: David Meyer To: Henry Sinnreich Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Message-ID: <20060525145309.GB14022@1-4-5.net> References: <072C5B76F7CEAB488172C6F64B30B5E3017E6597@xmb-rtp-20b.amer.cisco.com> <000b01c67f40$e3064030$2800a8c0@DSX400> Mime-Version: 1.0 In-Reply-To: <000b01c67f40$e3064030$2800a8c0@DSX400> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: "'Khan, Sohel Q \[CTO\]'" , speermint@ietf.org, 'Otmar Lendl' X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0758740717==" Errors-To: speermint-bounces@ietf.org --===============0758740717== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GID0FwUMdk1T2AWN" Content-Disposition: inline --GID0FwUMdk1T2AWN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 24, 2006 at 09:46:46AM -0500, Henry Sinnreich wrote: > I believe Mike is right on track. Overloading the DNS with application > protocol information, such as detailed policies for SIP is not what the D= NS > was designed for. >=20 > Going further down this path would make the DNS a successor of the AIN! Yes, and in addition, add the somewhat ("somewhat") ironic observation that while folks want to use the DNS for just about everything under the sun due to its reliability and reach, undisciplined overloading of the DNS will very likely destroy just that set of properties that people find attractive about it. --dmm --GID0FwUMdk1T2AWN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEdcTVORgD1qCZ2KcRAhABAJ9NdgkKAxVpWGmEbOKZAe/nAJXQnACfVYTY 72iyHFSeo8D0NW8C1gDQv1Y= =CADi -----END PGP SIGNATURE----- --GID0FwUMdk1T2AWN-- --===============0758740717== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0758740717==-- From speermint-bounces@ietf.org Thu May 25 12:07:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjIMg-0008TM-IN; Thu, 25 May 2006 12:07:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjIMf-0008TH-GU for speermint@ietf.org; Thu, 25 May 2006 12:07:09 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjIMe-00062u-6I for speermint@ietf.org; Thu, 25 May 2006 12:07:09 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 25 May 2006 12:07:08 -0400 X-IronPort-AV: i="4.05,173,1146456000"; d="scan'208"; a="89462623:sNHT31865392" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4PG77vF018920; Thu, 25 May 2006 12:07:07 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 May 2006 12:07:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Thu, 25 May 2006 12:07:05 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301847D95@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcZ/dbk5Vn0hJKKbTUK0XlyD+ErL1gAnO3BQ From: "Michael Hammer \(mhammer\)" To: "Otmar Lendl" X-OriginalArrivalTime: 25 May 2006 16:07:07.0411 (UTC) FILETIME=[456D7E30:01C68015] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: "Khan, Sohel Q \[CTO\]" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Otmar, If an address is advertized in public ENUM or DNS, then it ought not be unreachable due to use of private networks or NATs, which is the basis for some of your arguments about why not SIP. My thinking was that one would need to progress through a series of steps/functions where the bootstrap steps are very public, but the later steps depend on the previous step enabling it. The chicken or egg problem shouldn't occur for first steps. (I do understand your model where you advertise what is only reachable by a few, but then it is working as you intended with selective unreachability being part of your design.) Hopefully, any delays to call setup occur only because of initial contact to previously unknown domains. For, previously contacted domains or for federations that use a central SIP proxy or some interconnect SIP fabric, the call can be quickly handed to the heavily used local contact point for that federation, since they were learned previous to the call. Anyway, it may be possible through configuration to address both ways, with some heuristic to guide when to transition from the "policy is simple" approach to the "policy is complex" approach. Mike > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at]=20 > Sent: Wednesday, May 24, 2006 5:05 PM > To: Michael Hammer (mhammer) > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 >=20 > Michael, >=20 > On 2006/05/24 16:05, "Michael Hammer (mhammer)"=20 > wrote: > >=20 > > I think our main difference is that I am suspecting that the policy=20 > > will be large and possibly very dynamic, thus less suitable for=20 > > locating in DNS. Also, instead of pointing directly to a single=20 > > policy document, which seems like a one-size-fits-all periodic user=20 > > poll option,; rather, use Subscriptions where the resulting=20 > document=20 > > may depend on authentication and who is asking, and can be=20 > pushed on=20 > > the schedule of the server when the policy changes. >=20 > My guess is that the size of the policy will vary a great deal. >=20 > We don't know yet what the market will establish in the future. >=20 > That's why I used URIs are policy element identifiers. This=20 > gives us a wide range of options: >=20 > * Simple IDs which refer to offline established policies. (=3D=20 > federation > names) >=20 > * References to standards >=20 > * References to documents describing a complex policy >=20 > and (if you want a dynamic protocol) >=20 > * the location and connection parameters for any routing / > policy-exchange / ... protocol. >=20 > As an example (and not meant as a real proposal): let's=20 > assume that the destination requires the use of the Open=20 > Settlement Protocol. > We could standardize an URI scheme for that, e.g.=20 > "osp://hostname:port/" > and a suitable policy-record could thus be >=20 > NAPTR 10 10 "u" "D2P+SIP:osp" "!.*!osp://hostname:port/! . >=20 > You can do the same for your subscription model. >=20 > ---- >=20 > As for why you don't want to do all that with SIP, I refer to=20 > http://www1.ietf.org/mail-archive/web/speermint/current/msg00218.html >=20 > > These are just suggestions being thrown out for discussion.=20 > I'd like=20 > > to hear what folks think about them. >=20 > So do I. >=20 > > I'm also questioning how much information about SIP needs to be=20 > > embedded in other protocols like DNS, DHCP, etc. and how=20 > much might be=20 > > more cohesive if handled via SIP-based mechanisms. Finding=20 > the right=20 > > balance, if you will. >=20 > Indeed. My problem with a pure SIP solution is the following: > Assuming that members of some federations will opt to move=20 > their SIP ingress points to private IP networks and/or=20 > firewall them heavily I see a severe chicken and egg problem=20 > if the discovery of the correct SIP ingress point is done by=20 > a SIP exchange. >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu May 25 15:27:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjLUD-0000zQ-AI; Thu, 25 May 2006 15:27:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjLUB-0000zL-Ri for speermint@ietf.org; Thu, 25 May 2006 15:27:07 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjLUA-0006To-D0 for speermint@ietf.org; Thu, 25 May 2006 15:27:07 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k4PJR1S19414; Thu, 25 May 2006 15:27:02 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Thu, 25 May 2006 15:26:50 -0400 Message-ID: In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4A64@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAANiSfAAGpkGwABFyNDAABcvUoAAA7iiQAELeetA= From: "James McEachern" To: "Stastny Richard" , "Francois D. Menard" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org The original proposal that Francois made was that the minimum set of = RFCs was "SIP + RFC 3323 and RFC 3325". It appears that RFC 3323 has = been dropped from this list, but I don't recall seeing why. Have I = missed something? Jim -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Wednesday, May 24, 2006 7:34 AM To: Francois D. Menard; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >Yes, and presentation restriction, >So 3261, 3263, 3325 and 3326. >Sold! Bought! ;-) If anybody has any additions to this (for minimum requirements), he may holler IMHO in addition a BCP on the population of the header fields, particularly in context with phone numbers (e.164 and non-E.164) is required. A BCP on how to establish two-way TLS may also be useful Richard ________________________________ Von: Francois D. Menard [mailto:fmenard@xittelecom.com] Gesendet: Mi 24.05.2006 13:03 An: Stastny Richard Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Yes, and presentation restriction, So 3261, 3263, 3325 and 3326. Sold! F. -- Fran=E7ois D. M=E9nard Charg=E9 de projet Xit t=E9l=E9com inc. 1350 rue Royale #800 Trois-Rivi=E8res, QC, G9A 4J4 Canada fmenard@xittelecom.com Tel: (819) 374-2556 ext. 268 Fax: (819) 374-0395 Cell: (819) 692-1383 -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: 24 mai 2006 04:19 To: Michael Hammer (mhammer); Brian Rosen; Francois D. Menard; Khan, = Sohel Q [CTO]; David Meyer; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > A least common denominator set will likely be small, but perhaps not > sufficiently rich for any two wishing to peering. > e.g. RFC3261 and 3263 ;-) plus TLS and one kind of asserted identity additional richness could be provided by policy records Richard > Mike > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Tuesday, May 23, 2006 4:54 PM > > To: Michael Hammer (mhammer); Brian Rosen; Francois D. > > Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > >I think the the interworking of SIP to PSTN is out of scope here. > > > > Yes > > I did not find anything about this in the charter. > > It is not even mentioned in the out-of-scope section (which mentions > > at least H.323 ;-) > > > > >While coloring within those lines, the next question is > > whether there > > >is a single subset that can be defined or whether there will > > be many. > > >I am betting on many, probably a different set for each > > federation or > > >even bilateral pairing that might exist. > > > > I always had the idea that we could define minimum requrements > > (which could be the overlap of the many subsets) but maybe I am > > asking too much Or is SIP already as baroque at OSI FTAM was? > > (where we could only find bilateral "peerings" between DEC, IBM and > > Siemens, but not a subset with worked with all three ;-) > > > > Richard > > > > > > ________________________________ > > > > Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Gesendet: Di 23.05.2006 22:32 > > An: Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David > > Meyer; speermint@ietf.org > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > > > > > Brian, > > > > I think the the interworking of SIP to PSTN is out of scope here.=20 > > The issue is whether two peers, once they have discovered each > > other, can know what subset of SIP they need to support. I don't > > think there is any need to go down the rabbit hole on what > > applications are supported and whether they are PSTN emulations or > > simulations or whatever. We may know in the back of our mind that > > some application won't work if RFC X is not supported, but we don't > > need to discuss that. > > We need only to focus on what SIP RFCs are needed on the SIP peer > > interface. > > > > While coloring within those lines, the next question is whether > > there is a single subset that can be defined or whether there will > > be many. I am betting on many, probably a different set for each > > federation or even bilateral pairing that might exist. That could > > be another rabbit hole. > > I would be happy if two peers could point to the same subset and > > agree to use it, no matter how many subsets might exist. > > > > Mike > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Tuesday, May 23, 2006 3:05 PM > > > To: 'Francois D. Menard'; Michael Hammer (mhammer); 'Khan, Sohel Q > > > [CTO]'; 'David Meyer'; speermint@ietf.org > > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering > > Architecture > > > > > > By far the largest mistake EVER made by the IETF in the > > development of > > > SIP was to allow SIP to be extended to imitate the existing > > PSTN. If > > > we ever were to start again, the golden rule would be DON'T IMITATE > > > THE PSTN, and the corollary would be "Just because the PSTN does it > > > that way DOES NOT MEAN it's a good idea". > > > > > > So, the very idea that "replication of functionality in the > > > SS7 minimum message set" is the definition of what we need > > to do makes > > > me want to puke. > > > > > > No, and a pox on your houses for even thinking that. > > > > > > While we're going to start with "basic call", we need to > > define those > > > call features that must cross domain boundaries. > > > Most of them have existing SIP messaging (in sip-examples, for > > > instance). We need to make sure those features work across the > > > boundary. That has nothing whatsoever to do with an SS7 > > message. The > > > mms might give us clues on what features might be > > interesting to put > > > on our list, but I'll bet we end up with a lot less of them, and a > > > bunch of stuff not in SS7 (or C7); inter-domain presence, > > for example. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > > > Sent: Tuesday, May 23, 2006 2:50 PM > > > To: 'Michael Hammer (mhammer)'; 'Khan, Sohel Q [CTO]'; > > 'David Meyer'; > > > speermint@ietf.org > > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering > > Architecture > > > > > > > I don't see anything diametrically opposed between what I > > suggested > > > > and > > > what you are suggesting. > > > > > > I would be satisfied with this: > > > > > > SPEERMINT compliance requires replication of the functionality > > > available in the SS7 minumum message set which can be done by SIP, > > > 3323, 3325. Better than SS7 mms functionlality made possible with > > > ATIS, IP Sphere or other sip profiles will also be considered as > > > SPEERMIT compliant. > > > > > > > If there is to be an IETF-approved SIP profile, I think it should > > > > first be > > > decided if that is the turf of the Speermint or the SIP WG. > > > Those last two statements are at the heart of my concerns. > > > > > > SPEERMINT will be completely toothless as an RFC if it just states, > > > compliance with SPEERMINT can be achieved by compliance > > with non-IETF > > > standards. > > > > > > F. > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu May 25 15:36:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjLd2-0003AW-38; Thu, 25 May 2006 15:36:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjLd1-0003AR-F1 for speermint@ietf.org; Thu, 25 May 2006 15:36:15 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjLd0-0007D8-0W for speermint@ietf.org; Thu, 25 May 2006 15:36:15 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id A76541A367; Thu, 25 May 2006 21:36:12 +0200 (CEST) Date: Thu, 25 May 2006 21:36:12 +0200 From: Otmar Lendl To: "Michael Hammer (mhammer)" Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Message-ID: <20060525193612.GE1811@nic.at> Mail-Followup-To: Otmar Lendl , "Michael Hammer (mhammer)" , "Khan, Sohel Q [CTO]" , speermint@ietf.org References: <072C5B76F7CEAB488172C6F64B30B5E3017E6597@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3017E6597@xmb-rtp-20b.amer.cisco.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: "Khan, Sohel Q \[CTO\]" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Michael, On 2006/05/24 16:05, "Michael Hammer (mhammer)" wrote: > > I think our main difference is that I am suspecting that the policy will > be large and possibly very dynamic, thus less suitable for locating in > DNS. Also, instead of pointing directly to a single policy document, > which seems like a one-size-fits-all periodic user poll option,; rather, > use Subscriptions where the resulting document may depend on > authentication and who is asking, and can be pushed on the schedule of > the server when the policy changes. > > These are just suggestions being thrown out for discussion. I'd like to > hear what folks think about them. Re-reading your mail I found one aspect I'd like to highlight: If you talk about a "subscription" of some sort, I assume that you mean that the originating network kind of registeres at the destination network and receives updates about the state of this peering relationship. In a way, this sound similar to what BGP does. Have I interpreted this correctly? If not, please ignore the rest of this mail. The reason we decided NOT go this route is the following: Once you require that the border element of a SIP operator establishes a permanent session with the ingress elements of its peer before any calls can traverse this peering, then you almost require the manual configuration of this peering. That's fine if you take the peering model of BGP as reference. Layer 3 peering requires a physical connection (except at exchange points), peering is thus always an explicit and human decision and thus the manual BGP configuration is no issue. Peering at the SIP layer is different: you usually don't need build any extra physical connection. You can instantly peer with all other SIP services connected to the Internet once you're connected to it. The range of peering partners thus isn't limited to the ones to which you build a direct physical link. The set of potential peering partners is huge and reaching them does not involve any additional lower layer work. In the spirit of the Internet end-to-end model, I consider it thus essential to design a system with which all these VoIP operators can in effect establish peering relationships with each other. I won't force ubiquitous peering on all VSPs, but the system should make it possible. As an example, consider the following scenario: A set of VoIP service providers form an association and exchange traffic via the public Internet using SIP with the TCP/TLS transport protocol for confidentiality and peer authenticity by using X.509 certificates signed by the association's certificate authority. If a new operator joins such a club, what needs to happen? With domain policies the following: * the new guy get's his TLS cert signed * the new guy configures his ingress points to allow connections via TLS and a correct cert * he announces his membership in that federation by adding a NAPTR record to his domain That gives us O(n) scaling. Imagine what needs to happen if you have to configure BGP-like links: * the new guy has to estabish links to all existing members * and the reverse: all existing members have to be told about this new guy and have to configure their side of the peering link. This has complexity of O(n*n). (or do you have something similar like the BGP route-reflectors in mind?) --------------- If some group of operators want pre-configured links (and thus O(n*n) complexity), fine, let them do that within their federation. My proposal doesn't rule that out. On the other hand I think we should be extremely careful not to build something with precludes setups with far better scaling properties. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu May 25 16:21:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjMKt-0007f0-Qa; Thu, 25 May 2006 16:21:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjMKs-0007eu-TN for speermint@ietf.org; Thu, 25 May 2006 16:21:34 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FjMKr-0002Nh-M9 for speermint@ietf.org; Thu, 25 May 2006 16:21:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 May 2006 22:25:35 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A76@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Location Function in SPEERMINT Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAATumxgAG4BNwABEZoVAADQ2DIAAC1z/9AAGrFeAACZ2pfQABju7wACHfcEAAAbB9IAAK1HH6 From: "Stastny Richard" To: , "Michael Hammer \(mhammer\)" , , "Brian Rosen" , "Francois D. Menard" , "Khan, Sohel Q [CTO]" , "David Meyer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 562cdc9baa87554b29d950396a30cf75 Cc: Subject: [Speermint] Location Function in SPEERMINT X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi all, =20 sorry, but I am only able to reply with a short statement, because I am on vacation and have only limited time and bandwitdh (GPRS) First, I consider this discussion regarding Infrastructure ENUM, LERG = and LNP important, but in the wrong WG. It should be discussed in ENUM. WG and not in SPEERMINT =20 SPEERMINT is only dealing with Call Routing Data (CRD), which is defined as the OUTPUT of ENUM or some other means. This implies, that the location function (LF) defined in the achitecture draft happens AFTER an ENUM query and therefore cannot be the part of the LF. =20 The LF can only involve the location of the destination "network" as defined in SPEERMINT by the use of CRD (which is basically a SIP URI because we are currently talking only SIP in SPEERMINT) =20 Of course SPEERMINT needs to define what it considers CRD, and AoR or the ingress point of a network. BUT then SPEERMINT needs also to define how the ingress point of a "network" is LOCATED given a SIP AoR. =20 Richard =20 ________________________________ Von: Tim Dwight [mailto:timothy.dwight@verizon.com] Gesendet: Do 25.05.2006 20:17 An: 'Michael Hammer (mhammer)'; timothy.dwight@verizon.com; Stastny = Richard; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; = 'David Meyer'; speermint@ietf.org Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - = SF Michael Hammer said: > Tim, > > The LERG and LNP databases are intrinsically tied to the operation of = the TDM > infrastructure. Any design that perpatuates these systems when their reason > for being (TDM) goes away is a faulty design. OK with me. I only meant to point out that right now I have these capabilities, so recreating them isn't a high priority. > > DNS and ENUM provides the equivalent information and mechanisms to do = what is > needed in the IP domain. As such, a design that makes dependencies on legacy > systems is deficient. I wouldn't support such a kludge. Fine. I'm a big fan of IP-domain solutions. Specifically Infrastructure ENUM looks really handy; my point before was that it's moreso when used in = what Richard called "option 1". The alternative ("option 2") only replicates = the "kludge" to which I already have access. And to be fair to Richard, he did point out (subtly) that the latter = claim is a bit myopic. There are existing means by which VSPs can gain access = to number portability information relative to national destinations. They don't have such access, at least not easily and not universally, to = number portability information relative to international destinations. If that could be provided by Infrastructure ENUM (either "option 1" or "option = 2") it would be useful and would not simply replicate existing capabilities. Bottom line, both options defined by Richard, would add value. Option 1 adds more value but is specific to destinations identified by E.164 = numbers or URIs with imbedded E.164 numbers. Which is the problem closest to = hand. > > That said, if there are backward compatibilities during the = transition, where > some information just happens to be known by external systems, such as = you suggest > below, I don't see that as a problem. I am just wary of ending up = with two > systems in the end when one would do. Isn't it inevitable that for some time, both will exist? Just as the = GSTN and VoIP will coexist for some time, so will their supporting infrastructure. Don't get me wrong. I'm not saying "because I have an SS7 -based = solution to LNP I don't need an IP -based solution". All I'm saying is that when given the option of using Infrastructure ENUM to recreate (and in the = case of international destinations, extend) the capability I already have, = and using it to do that and more, I'm inclined to prefer the latter.=20 > > Mike > -----Original Message----- > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > Sent: Wednesday, May 24, 2006 6:19 PM > To: 'Stastny Richard'; timothy.dwight@verizon.com; > timothy.dwight@verizon.com; Michael Hammer (mhammer); 'Brian Rosen'; > 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; > speermint@ietf.org > Subject: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF > - SF > > Richard, > > Yes I know I was mixing data and mechanism-to-access-data.=20 > Still I believe the major point to be correct. In many parts of the > world there are already mechanisms (associated with Local Number > Portability) to determine ownership of an E.164 number, hence use of > ENUM for this purpose alone, will be unnecessary. > > To be clear, I believe that providing access via Infrastructure ENUM > to LNP information may be very helpful; but only if Infrastructure > ENUM provides more than just this. > If an Infrastructure ENUM query can combine (a) determination of the > entity providing service to the destination, (b) determination of the > corresponding LRN, if one exists, and (c) mapping of the routable > number (either the number originally indicated, or the LRN) to a Layer > 5 "point of ingress" specified by the entity providing service to the > destination; then Infrastructure ENUM is quite a handy mechanism. If > all it does is (a) then I don't need it. > > But in the end this is neither here nor there. I am not wedded to any > specific technology, I just need workable solutions to real business > problems. > > Tim > > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, May 24, 2006 4:38 PM > To: timothy.dwight@verizon.com; timothy.dwight@verizon.com; Michael > Hammer (mhammer); Brian Rosen; Francois D. Menard; Khan, Sohel Q > [CTO]; David Meyer; speermint@ietf.org > Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF > - SF > > Tim, >=20 > thanx for your reply, you are raising some important issues. > Since it is already midnight here, I will reply to it in detail > tomorrow >=20 > I am also working on a more detailed analysis and a draft which will > require even some more time. >=20 > Just a quick one: >=20 > >In some parts of the world the function provided by "option > 2" usage of > >Infrastructure ENUM could be achieved in other ways (e.g., > the LERG and > >NPDB in North America) so in those cases Infrastructure ENUM > might be a > >superfluous concept; but if that's the right technical > answer so be it. >=20 > Yes and no ;-) > You are mixing up here the Registry and the ENUM DNS. > The Registry is the LERG and NPDB (or is derived from), the ENUM DNS > is the equivalent on IP of the SCP in the PSTN where the date is > downloaded to. >=20 > Richard >=20 > > ________________________________ > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > Gesendet: Mi 24.05.2006 23:00 > An: Stastny Richard; timothy.dwight@verizon.com; 'Michael Hammer > (mhammer)'; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q > [CTO]'; 'David Meyer'; speermint@ietf.org > Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF > - SF > > > > Richard, > > Thank you for the clarification. I understand the distinction you are > making. > > My objective is to be able to translate a destination identifier > (E.164 number of alphanumeric AoR) into the address of a Layer 5 > entity designated by the organization providing service to the called > party. With infrastructure/carrier ENUM I could do this (as described > in your Option 1), but because ENUM is specific to E.164 numbers it > would only work for E.164 -formatted destination identifiers. > > In pictures, your Option 2 seems to me to imply the following: > > +----------------+ +----------+ > E.164 | infrastructure | serving | identify > | network > ingress > destination -->| ENUM |---> carrier --->| ingress=20 > |---> point > specified > identifier | (option 2) | identity | point | by > serving carrier > +----------------+ ^ +----------+ > | > +----------------+ | > non-E.164 | map domain in | | > Destination -->| URI to carrier |--------+ > Identifier | identity | > +----------------+ > > In some parts of the world the function provided by "option 2" usage > of Infrastructure ENUM could be achieved in other ways (e.g., the LERG > and NPDB in North America) so in those cases Infrastructure ENUM might > be a superfluous concept; but if that's the right technical answer so > be it. > > The "identify ingress point" function would need to be defined. I > would like it to consider the specified destination (in addition to > the carrier providing service to that destination); and I would like > the procedures to be such that the serving carrier controls (in a > reasonably dynamic > way) the point at which traffic destined to a particular destination, > enters his network. If those requirements can be met, I think this > approach is workable. > > Its biggest drawback is that it precludes a solution ("option 1" usage > of Infrastructure ENUM) that is sufficient for the majority of today's > needs. > It optimizes for a problem that will exist in the future at the > expense of solving problems that exist today. I realize that solving > today's problems may not be SPEERMINT's focus, or (arguably) even > within its charter, but I would hate to see recommendations from > SPEERMINT preclude or significantly delay solving them. > > Suppose we did something like this: > > +----------+ [pseudo +----------------+ > non-E.164 | identify | or real] | infrastructure > | network > ingress > destination -->| "pseudo" |---> E.164 --->| ENUM =20 > |---> point > specified > identifier | E.164 | number | (option 1) | by > serving carrier > +----------+ +----------------+ > > We could let the ENUM working group define Infrastructure ENUM as > described in your Option 1 (which is as you know already commercially > available from a few sources) and SPEERMINT could define the "identify > pseudo E.164" function that in my diagram feeds into it. This > function might be as simple as mapping the domain part of the URI to > an E.164 number uniquely associated with the network providing service > to the specified destination. Unless this is a lot harder than it > seems, this shouldn't keep us busy too long :-) > > > Tim > > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, May 24, 2006 11:16 AM > To: timothy.dwight@verizon.com; Michael Hammer (mhammer); > Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David > Meyer; speermint@ietf.org > Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture - > LF - OF - SF > > Tim, > > >> ... the basic idea of Infrastructure ENUM (which will be used for > >> service providers is to provide a domain name in a SIP URI =3D a > >> service provider ID > >(SPID) > > >At the risk of asking an off-topic question (realizing that > ENUM is not > >within scope for SPEERMINT), can I ask where the idea that > >Infrastructure ENUM queries return SPIDs, comes from? It is > my intent > >to provide a point of interconnection to be used by the requesting > >entity to hand to me a call to the specified number. I do > not intend > >that the only meaningful part of the URI returned from the > ENUM query, > >be > the domain name. > > thank you for raising this important point. I tried to raise > this some time ago, but got no clear answer > > Currently there exist two lines of thought about the usage of > Infrastructure (and also Carrier ENUM in private trees) > > 1. Put in ENUM the ingress point(s) e.g. > sip:+43xxxx@sbc4711.provider.net 2. > Put in ENUM the AoR only: e.g. sip:+43xxx@provider.net > (provider.net is what I meant with SPID) > > Most currently prefer option 1, especially in private ENUM trees. > > IMHO this is the wrong approach: > > There should be a clear separation (and it is in the charter) > between ENUM and SPEERMINT SPEERMINT peering MUST be able to > work standalone and without ENUM. > > Option 1 assumes also that the user is entering ALWAYS an > E.164 number as identifier. > > But what if he is entering an AoR? > > SPEEMINT peering MUST be able to resolve this too so you need > to find the ingress point independant of ENUM e.g. via RFC3263. > > If this MUST be possible, why not enter in (any) ENUM just > the AoR, if you must be able to resolve the AoR anyway? > > Otherwise you need to manage two mappings separate 1. the > E.164 to ingress point 2. the AoR mapping to ingress point > > this is not a good idea > > This is the reason why I would prefer to enter in ENUM AoRs > only the user part in ENUM is always the E.164 number (for > privacy reasons) the domain part is the SPID, which is mapped > later to find the ingress point > > the calling user may then also use an alis AoR such as > sip:name@provider.net > > regards > > Richard > > > > ________________________________ > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > Gesendet: Mi 24.05.2006 16:46 > An: Stastny Richard; 'Michael Hammer (mhammer)'; 'Brian > Rosen'; 'Francois D. > Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; speermint@ietf.org > Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - > LF - OF - SF > > > > Stastny, Richard said: > > > ... the basic idea of Infrastructure ENUM (which will be used for > > service providers is to provide a domain name in a SIP URI > =3D a service > > provider ID > (SPID) > > At the risk of asking an off-topic question (realizing that > ENUM is not within scope for SPEERMINT), can I ask where the > idea that Infrastructure ENUM queries return SPIDs, comes > from? It is my intent to provide a point of interconnection > to be used by the requesting entity to hand to me a call to > the specified number. I do not intend that the only > meaningful part of the URI returned from the ENUM query, be > the domain name. > > tim > > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu May 25 16:35:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjMYM-00009p-VG; Thu, 25 May 2006 16:35:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjMYL-00009k-Ro for speermint@ietf.org; Thu, 25 May 2006 16:35:29 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjMYK-0003bF-9q for speermint@ietf.org; Thu, 25 May 2006 16:35:29 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 25 May 2006 13:35:27 -0700 X-IronPort-AV: i="4.05,173,1146466800"; d="scan'208"; a="553569925:sNHT37866680" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Thu, 25 May 2006 16:35:25 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804652CCC@proton.jnpr.net> In-Reply-To: <20060525193612.GE1811@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaAMpRWMDzepi+2STqwIU3/2FkSOwAAR2aA From: "Reinaldo Penno" To: "Otmar Lendl" , "Michael Hammer \(mhammer\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: "Khan, Sohel Q \[CTO\]" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Joining in.... I believe your proposal could make sense in some settlement free (business or otherwise) environment like those VoIP peering points in Europe. I could also take your proposal even further and argue that everybody will have a domain name and SIP server at their homes and peer directly over TLS with the domain to which the call is destined. This will create a O(n^2) where n is quite large. My guess is that in reality many ISPs, MSOs and Carries will peer at specific peering points with well defined rules. The big players will provide peering service for the small ones being them enterprise or otherwise. This would reduce the O(n^2) that you are so worried about.=20 So, good news, it is already like this. Global carriers already provide the link and VoIP services for big enterprises. Smaller ISP use big ones for transit, etc, etc=20 I bet there will also be tons of consolidation amongst pure VSPs and many of them will just go chapter 11 when competing with big carriers. But now we are in the VSP feeding frenzy... I also do not follow your example below. It seems you are bundling several control aspect functions. In the BGP model you establish a TCP connection with each peer and exchange routing tables. In the TLS model you also establish one connection with each peer to exchange SIP control traffic. How's that different? What do you call links? The only difference between the models (DNS vs. subscription) that you could argue is what routing people call membership and discovery. What you say is that discovery and membership is faster with a DNS model.=20 I would argue that in all cases DNS could be used for location (apart from manual configuration) and in non ad-hoc peering scenarios subscription provides a quasi instantaneous notification when a peering policy changes, it does not involve any third party server, and can carry variable amounts of data, and already possess all security features existing in SIP.=20 As for the subscription-reflector, it is an idea that comes to mind when hundreds of VSP need to peer. I do not think a scalable SIP server handling possibly >> 200caps (my guess number) will have any problems handling a few dozens subscriptions.=20 Regards, Reinaldo > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Thursday, May 25, 2006 12:36 PM > To: Michael Hammer (mhammer) > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 >=20 > Michael, >=20 > On 2006/05/24 16:05, "Michael Hammer (mhammer)" wrote: > > > > I think our main difference is that I am suspecting that the policy will > > be large and possibly very dynamic, thus less suitable for locating in > > DNS. Also, instead of pointing directly to a single policy document, > > which seems like a one-size-fits-all periodic user poll option,; rather, > > use Subscriptions where the resulting document may depend on > > authentication and who is asking, and can be pushed on the schedule of > > the server when the policy changes. > > > > These are just suggestions being thrown out for discussion. I'd like to > > hear what folks think about them. >=20 > Re-reading your mail I found one aspect I'd like to highlight: >=20 > If you talk about a "subscription" of some sort, I assume that > you mean that the originating network kind of registeres at the > destination network and receives updates about the state of this peering > relationship. In a way, this sound similar to what BGP does. >=20 > Have I interpreted this correctly? If not, please ignore the rest of this > mail. >=20 > The reason we decided NOT go this route is the following: >=20 > Once you require that the border element of a SIP operator > establishes a permanent session with the ingress elements > of its peer before any calls can traverse this peering, then > you almost require the manual configuration of this peering. >=20 > That's fine if you take the peering model of BGP as reference. > Layer 3 peering requires a physical connection (except at exchange > points), peering is thus always an explicit and human decision and thus > the manual BGP configuration is no issue. >=20 > Peering at the SIP layer is different: you usually don't need build any > extra physical connection. You can instantly peer with all other SIP > services connected to the Internet once you're connected to it. The > range of peering partners thus isn't limited to the ones to which you > build a direct physical link. The set of potential peering partners is > huge and reaching them does not involve any additional lower layer work. >=20 > In the spirit of the Internet end-to-end model, I consider it thus > essential to design a system with which all these VoIP operators > can in effect establish peering relationships with each other. > I won't force ubiquitous peering on all VSPs, but the system should > make it possible. >=20 > As an example, consider the following scenario: >=20 > A set of VoIP service providers form an association and exchange traffic > via the public Internet using SIP with the TCP/TLS transport protocol > for confidentiality and peer authenticity by using X.509 certificates > signed by the association's certificate authority. >=20 > If a new operator joins such a club, what needs to happen? >=20 > With domain policies the following: >=20 > * the new guy get's his TLS cert signed > * the new guy configures his ingress points to allow connections > via TLS and a correct cert > * he announces his membership in that federation by adding a NAPTR > record to his domain >=20 > That gives us O(n) scaling. >=20 > Imagine what needs to happen if you have to configure BGP-like links: >=20 > * the new guy has to estabish links to all existing members > * and the reverse: all existing members have to be told about this > new guy and have to configure their side of the peering link. >=20 > This has complexity of O(n*n). >=20 > (or do you have something similar like the BGP route-reflectors in mind?) >=20 > --------------- >=20 > If some group of operators want pre-configured links (and thus O(n*n) > complexity), fine, let them do that within their federation. > My proposal doesn't rule that out. >=20 > On the other hand I think we should be extremely careful not to build > something with precludes setups with far better scaling properties. >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu May 25 16:37:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjMaD-000335-E8; Thu, 25 May 2006 16:37:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjMaC-0002pU-0m for speermint@ietf.org; Thu, 25 May 2006 16:37:24 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjMaB-0003rT-6Y for speermint@ietf.org; Thu, 25 May 2006 16:37:23 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 25 May 2006 13:37:22 -0700 X-IronPort-AV: i="4.05,173,1146466800"; d="scan'208"; a="549277745:sNHT49770564" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Location Function in SPEERMINT Date: Thu, 25 May 2006 16:37:18 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804652CCE@proton.jnpr.net> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4A76@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Location Function in SPEERMINT Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAATumxgAG4BNwABEZoVAADQ2DIAAC1z/9AAGrFeAACZ2pfQABju7wACHfcEAAAbB9IAAK1HH6AAC9BtA= From: "Reinaldo Penno" To: "Stastny Richard" , , "Michael Hammer \(mhammer\)" , , "Brian Rosen" , "Francois D. Menard" , "Khan, Sohel Q [CTO]" , "David Meyer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 43ca87c8fcef5d9f6e966e1c3917103e Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, May 25, 2006 1:26 PM > To: timothy.dwight@verizon.com; Michael Hammer (mhammer); > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, Sohel Q > [CTO]; David Meyer; speermint@ietf.org > Subject: [Speermint] Location Function in SPEERMINT >=20 > Hi all, >=20 > sorry, but I am only able to reply with a short statement, because I am > on vacation and have only limited time and bandwitdh (GPRS) >=20 > First, I consider this discussion regarding Infrastructure ENUM, LERG and > LNP > important, but in the wrong WG. It should be discussed in ENUM. WG and > not in SPEERMINT >=20 > SPEERMINT is only dealing with Call Routing Data (CRD), which is defined > as the OUTPUT of ENUM or some other means. >=20 > This implies, that the location function (LF) defined in the > achitecture draft happens AFTER an ENUM query and therefore > cannot be the part of the LF. >=20 > The LF can only involve the location of the destination "network" > as defined in SPEERMINT by the use of CRD (which > is basically a SIP URI because we are currently talking only SIP > in SPEERMINT) >=20 > Of course SPEERMINT needs to define what it considers CRD, > and AoR or the ingress point of a network. >=20 > BUT then SPEERMINT needs also to define how the ingress > point of a "network" is LOCATED given a SIP AoR. [[Reinaldo]]=20 That's maybe one of the most important issues. This could be complicated by the geographically dispersed networks with several entry points. Although this might be an interesting problem it might be a rathole. >=20 > Richard >=20 >=20 > ________________________________ >=20 > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > Gesendet: Do 25.05.2006 20:17 > An: 'Michael Hammer (mhammer)'; timothy.dwight@verizon.com; Stastny > Richard; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; > 'David Meyer'; speermint@ietf.org > Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF >=20 >=20 >=20 > Michael Hammer said: >=20 > > Tim, > > > > The LERG and LNP databases are intrinsically tied to the operation of > the > TDM > > infrastructure. Any design that perpatuates these systems when their > reason > > for being (TDM) goes away is a faulty design. >=20 > OK with me. I only meant to point out that right now I have these > capabilities, so recreating them isn't a high priority. >=20 >=20 > > > > DNS and ENUM provides the equivalent information and mechanisms to do > what > is > > needed in the IP domain. As such, a design that makes dependencies on > legacy > > systems is deficient. I wouldn't support such a kludge. >=20 > Fine. >=20 > I'm a big fan of IP-domain solutions. Specifically Infrastructure ENUM > looks really handy; my point before was that it's moreso when used in what > Richard called "option 1". The alternative ("option 2") only replicates > the > "kludge" to which I already have access. >=20 > And to be fair to Richard, he did point out (subtly) that the latter claim > is a bit myopic. There are existing means by which VSPs can gain access > to > number portability information relative to national destinations. They > don't have such access, at least not easily and not universally, to number > portability information relative to international destinations. If that > could be provided by Infrastructure ENUM (either "option 1" or "option 2") > it would be useful and would not simply replicate existing capabilities. >=20 > Bottom line, both options defined by Richard, would add value. Option 1 > adds more value but is specific to destinations identified by E.164 > numbers > or URIs with imbedded E.164 numbers. Which is the problem closest to > hand. >=20 >=20 > > > > That said, if there are backward compatibilities during the transition, > where > > some information just happens to be known by external systems, such as > you > suggest > > below, I don't see that as a problem. I am just wary of ending up with > two > > systems in the end when one would do. >=20 > Isn't it inevitable that for some time, both will exist? Just as the GSTN > and VoIP will coexist for some time, so will their supporting > infrastructure. >=20 > Don't get me wrong. I'm not saying "because I have an SS7 -based solution > to LNP I don't need an IP -based solution". All I'm saying is that when > given the option of using Infrastructure ENUM to recreate (and in the case > of international destinations, extend) the capability I already have, and > using it to do that and more, I'm inclined to prefer the latter. >=20 >=20 > > > > Mike >=20 >=20 > > -----Original Message----- > > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > > Sent: Wednesday, May 24, 2006 6:19 PM > > To: 'Stastny Richard'; timothy.dwight@verizon.com; > > timothy.dwight@verizon.com; Michael Hammer (mhammer); 'Brian Rosen'; > > 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; > > speermint@ietf.org > > Subject: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF > > - SF > > > > Richard, > > > > Yes I know I was mixing data and mechanism-to-access-data. > > Still I believe the major point to be correct. In many parts of the > > world there are already mechanisms (associated with Local Number > > Portability) to determine ownership of an E.164 number, hence use of > > ENUM for this purpose alone, will be unnecessary. > > > > To be clear, I believe that providing access via Infrastructure ENUM > > to LNP information may be very helpful; but only if Infrastructure > > ENUM provides more than just this. > > If an Infrastructure ENUM query can combine (a) determination of the > > entity providing service to the destination, (b) determination of the > > corresponding LRN, if one exists, and (c) mapping of the routable > > number (either the number originally indicated, or the LRN) to a Layer > > 5 "point of ingress" specified by the entity providing service to the > > destination; then Infrastructure ENUM is quite a handy mechanism. If > > all it does is (a) then I don't need it. > > > > But in the end this is neither here nor there. I am not wedded to any > > specific technology, I just need workable solutions to real business > > problems. > > > > Tim > > > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, May 24, 2006 4:38 PM > > To: timothy.dwight@verizon.com; timothy.dwight@verizon.com; Michael > > Hammer (mhammer); Brian Rosen; Francois D. Menard; Khan, Sohel Q > > [CTO]; David Meyer; speermint@ietf.org > > Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF > > - SF > > > > Tim, > > > > thanx for your reply, you are raising some important issues. > > Since it is already midnight here, I will reply to it in detail > > tomorrow > > > > I am also working on a more detailed analysis and a draft which will > > require even some more time. > > > > Just a quick one: > > > > >In some parts of the world the function provided by "option > > 2" usage of > > >Infrastructure ENUM could be achieved in other ways (e.g., > > the LERG and > > >NPDB in North America) so in those cases Infrastructure ENUM > > might be a > > >superfluous concept; but if that's the right technical > > answer so be it. > > > > Yes and no ;-) > > You are mixing up here the Registry and the ENUM DNS. > > The Registry is the LERG and NPDB (or is derived from), the ENUM DNS > > is the equivalent on IP of the SCP in the PSTN where the date is > > downloaded to. > > > > Richard > > > > > > ________________________________ > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > Gesendet: Mi 24.05.2006 23:00 > > An: Stastny Richard; timothy.dwight@verizon.com; 'Michael Hammer > > (mhammer)'; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q > > [CTO]'; 'David Meyer'; speermint@ietf.org > > Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF > > - SF > > > > > > > > Richard, > > > > Thank you for the clarification. I understand the distinction you are > > making. > > > > My objective is to be able to translate a destination identifier > > (E.164 number of alphanumeric AoR) into the address of a Layer 5 > > entity designated by the organization providing service to the called > > party. With infrastructure/carrier ENUM I could do this (as described > > in your Option 1), but because ENUM is specific to E.164 numbers it > > would only work for E.164 -formatted destination identifiers. > > > > In pictures, your Option 2 seems to me to imply the following: > > > > +----------------+ +----------+ > > E.164 | infrastructure | serving | identify > > | network > > ingress > > destination -->| ENUM |---> carrier --->| ingress > > |---> point > > specified > > identifier | (option 2) | identity | point | by > > serving carrier > > +----------------+ ^ +----------+ > > | > > +----------------+ | > > non-E.164 | map domain in | | > > Destination -->| URI to carrier |--------+ > > Identifier | identity | > > +----------------+ > > > > In some parts of the world the function provided by "option 2" usage > > of Infrastructure ENUM could be achieved in other ways (e.g., the LERG > > and NPDB in North America) so in those cases Infrastructure ENUM might > > be a superfluous concept; but if that's the right technical answer so > > be it. > > > > The "identify ingress point" function would need to be defined. I > > would like it to consider the specified destination (in addition to > > the carrier providing service to that destination); and I would like > > the procedures to be such that the serving carrier controls (in a > > reasonably dynamic > > way) the point at which traffic destined to a particular destination, > > enters his network. If those requirements can be met, I think this > > approach is workable. > > > > Its biggest drawback is that it precludes a solution ("option 1" usage > > of Infrastructure ENUM) that is sufficient for the majority of today's > > needs. > > It optimizes for a problem that will exist in the future at the > > expense of solving problems that exist today. I realize that solving > > today's problems may not be SPEERMINT's focus, or (arguably) even > > within its charter, but I would hate to see recommendations from > > SPEERMINT preclude or significantly delay solving them. > > > > Suppose we did something like this: > > > > +----------+ [pseudo +----------------+ > > non-E.164 | identify | or real] | infrastructure > > | network > > ingress > > destination -->| "pseudo" |---> E.164 --->| ENUM > > |---> point > > specified > > identifier | E.164 | number | (option 1) | by > > serving carrier > > +----------+ +----------------+ > > > > We could let the ENUM working group define Infrastructure ENUM as > > described in your Option 1 (which is as you know already commercially > > available from a few sources) and SPEERMINT could define the "identify > > pseudo E.164" function that in my diagram feeds into it. This > > function might be as simple as mapping the domain part of the URI to > > an E.164 number uniquely associated with the network providing service > > to the specified destination. Unless this is a lot harder than it > > seems, this shouldn't keep us busy too long :-) > > > > > > Tim > > > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, May 24, 2006 11:16 AM > > To: timothy.dwight@verizon.com; Michael Hammer (mhammer); > > Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David > > Meyer; speermint@ietf.org > > Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture - > > LF - OF - SF > > > > Tim, > > > > >> ... the basic idea of Infrastructure ENUM (which will be used for > > >> service providers is to provide a domain name in a SIP URI =3D a > > >> service provider ID > > >(SPID) > > > > >At the risk of asking an off-topic question (realizing that > > ENUM is not > > >within scope for SPEERMINT), can I ask where the idea that > > >Infrastructure ENUM queries return SPIDs, comes from? It is > > my intent > > >to provide a point of interconnection to be used by the requesting > > >entity to hand to me a call to the specified number. I do > > not intend > > >that the only meaningful part of the URI returned from the > > ENUM query, > > >be > > the domain name. > > > > thank you for raising this important point. I tried to raise > > this some time ago, but got no clear answer > > > > Currently there exist two lines of thought about the usage of > > Infrastructure (and also Carrier ENUM in private trees) > > > > 1. Put in ENUM the ingress point(s) e.g. > > sip:+43xxxx@sbc4711.provider.net 2. > > Put in ENUM the AoR only: e.g. sip:+43xxx@provider.net > > (provider.net is what I meant with SPID) > > > > Most currently prefer option 1, especially in private ENUM trees. > > > > IMHO this is the wrong approach: > > > > There should be a clear separation (and it is in the charter) > > between ENUM and SPEERMINT SPEERMINT peering MUST be able to > > work standalone and without ENUM. > > > > Option 1 assumes also that the user is entering ALWAYS an > > E.164 number as identifier. > > > > But what if he is entering an AoR? > > > > SPEEMINT peering MUST be able to resolve this too so you need > > to find the ingress point independant of ENUM e.g. via RFC3263. > > > > If this MUST be possible, why not enter in (any) ENUM just > > the AoR, if you must be able to resolve the AoR anyway? > > > > Otherwise you need to manage two mappings separate 1. the > > E.164 to ingress point 2. the AoR mapping to ingress point > > > > this is not a good idea > > > > This is the reason why I would prefer to enter in ENUM AoRs > > only the user part in ENUM is always the E.164 number (for > > privacy reasons) the domain part is the SPID, which is mapped > > later to find the ingress point > > > > the calling user may then also use an alis AoR such as > > sip:name@provider.net > > > > regards > > > > Richard > > > > > > > > ________________________________ > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > Gesendet: Mi 24.05.2006 16:46 > > An: Stastny Richard; 'Michael Hammer (mhammer)'; 'Brian > > Rosen'; 'Francois D. > > Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; speermint@ietf.org > > Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - > > LF - OF - SF > > > > > > > > Stastny, Richard said: > > > > > ... the basic idea of Infrastructure ENUM (which will be used for > > > service providers is to provide a domain name in a SIP URI > > =3D a service > > > provider ID > > (SPID) > > > > At the risk of asking an off-topic question (realizing that > > ENUM is not within scope for SPEERMINT), can I ask where the > > idea that Infrastructure ENUM queries return SPIDs, comes > > from? It is my intent to provide a point of interconnection > > to be used by the requesting entity to hand to me a call to > > the specified number. I do not intend that the only > > meaningful part of the URI returned from the ENUM query, be > > the domain name. > > > > tim > > > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu May 25 16:48:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjMkQ-0000R8-5H; Thu, 25 May 2006 16:47:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjMkP-0000R3-9t for speermint@ietf.org; Thu, 25 May 2006 16:47:57 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FjMkO-0004nU-0I for speermint@ietf.org; Thu, 25 May 2006 16:47:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Location Function in SPEERMINT Date: Thu, 25 May 2006 22:52:01 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A77@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Location Function in SPEERMINT Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAATumxgAG4BNwABEZoVAADQ2DIAAC1z/9AAGrFeAACZ2pfQABju7wACHfcEAAAbB9IAAK1HH6AAC9BtAAAGOAdA== From: "Stastny Richard" To: "Reinaldo Penno" , , "Michael Hammer \(mhammer\)" , , "Brian Rosen" , "Francois D. Menard" , "Khan, Sohel Q [CTO]" , "David Meyer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 3da7e5d5ca82d58872786934e4963616 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Reinaldo said: >That's maybe one of the most important issues. This could be = complicated >by the geographically dispersed networks with several entry points. >Although this might be an interesting problem it might be a rathole. So you say RFC 3263 is not enough, something is missing? e.g. the geographic location of originating and terminating --- what? -SIP proxy? who cares -SBC? -UA? =20 So we are again dealing with SBCs, in this case the geo-location of = these -- rats, holes ;-) =20 Richard=20 ________________________________ Von: Reinaldo Penno [mailto:rpenno@juniper.net] Gesendet: Do 25.05.2006 22:37 An: Stastny Richard; timothy.dwight@verizon.com; Michael Hammer = (mhammer); timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; = Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org Betreff: RE: [Speermint] Location Function in SPEERMINT > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, May 25, 2006 1:26 PM > To: timothy.dwight@verizon.com; Michael Hammer (mhammer); > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, Sohel Q > [CTO]; David Meyer; speermint@ietf.org > Subject: [Speermint] Location Function in SPEERMINT > > Hi all, > > sorry, but I am only able to reply with a short statement, because I am > on vacation and have only limited time and bandwitdh (GPRS) > > First, I consider this discussion regarding Infrastructure ENUM, LERG and > LNP > important, but in the wrong WG. It should be discussed in ENUM. WG and > not in SPEERMINT > > SPEERMINT is only dealing with Call Routing Data (CRD), which is defined > as the OUTPUT of ENUM or some other means. > > This implies, that the location function (LF) defined in the > achitecture draft happens AFTER an ENUM query and therefore > cannot be the part of the LF. > > The LF can only involve the location of the destination "network" > as defined in SPEERMINT by the use of CRD (which > is basically a SIP URI because we are currently talking only SIP > in SPEERMINT) > > Of course SPEERMINT needs to define what it considers CRD, > and AoR or the ingress point of a network. > > BUT then SPEERMINT needs also to define how the ingress > point of a "network" is LOCATED given a SIP AoR. [[Reinaldo]] That's maybe one of the most important issues. This could be complicated by the geographically dispersed networks with several entry points. Although this might be an interesting problem it might be a rathole. > > Richard > > > ________________________________ > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > Gesendet: Do 25.05.2006 20:17 > An: 'Michael Hammer (mhammer)'; timothy.dwight@verizon.com; Stastny > Richard; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; > 'David Meyer'; speermint@ietf.org > Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF > > > > Michael Hammer said: > > > Tim, > > > > The LERG and LNP databases are intrinsically tied to the operation of > the > TDM > > infrastructure. Any design that perpatuates these systems when their > reason > > for being (TDM) goes away is a faulty design. > > OK with me. I only meant to point out that right now I have these > capabilities, so recreating them isn't a high priority. > > > > > > DNS and ENUM provides the equivalent information and mechanisms to do > what > is > > needed in the IP domain. As such, a design that makes dependencies on > legacy > > systems is deficient. I wouldn't support such a kludge. > > Fine. > > I'm a big fan of IP-domain solutions. Specifically Infrastructure ENUM > looks really handy; my point before was that it's moreso when used in what > Richard called "option 1". The alternative ("option 2") only replicates > the > "kludge" to which I already have access. > > And to be fair to Richard, he did point out (subtly) that the latter claim > is a bit myopic. There are existing means by which VSPs can gain access > to > number portability information relative to national destinations. They > don't have such access, at least not easily and not universally, to number > portability information relative to international destinations. If that > could be provided by Infrastructure ENUM (either "option 1" or "option 2") > it would be useful and would not simply replicate existing capabilities. > > Bottom line, both options defined by Richard, would add value. Option 1 > adds more value but is specific to destinations identified by E.164 > numbers > or URIs with imbedded E.164 numbers. Which is the problem closest to > hand. > > > > > > That said, if there are backward compatibilities during the transition, > where > > some information just happens to be known by external systems, such as > you > suggest > > below, I don't see that as a problem. I am just wary of ending up with > two > > systems in the end when one would do. > > Isn't it inevitable that for some time, both will exist? Just as the GSTN > and VoIP will coexist for some time, so will their supporting > infrastructure. > > Don't get me wrong. I'm not saying "because I have an SS7 -based solution > to LNP I don't need an IP -based solution". All I'm saying is that when > given the option of using Infrastructure ENUM to recreate (and in the case > of international destinations, extend) the capability I already have, and > using it to do that and more, I'm inclined to prefer the latter. > > > > > > Mike > > > > -----Original Message----- > > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > > Sent: Wednesday, May 24, 2006 6:19 PM > > To: 'Stastny Richard'; timothy.dwight@verizon.com; > > timothy.dwight@verizon.com; Michael Hammer (mhammer); 'Brian Rosen'; > > 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; > > speermint@ietf.org > > Subject: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF > > - SF > > > > Richard, > > > > Yes I know I was mixing data and mechanism-to-access-data. > > Still I believe the major point to be correct. In many parts of the > > world there are already mechanisms (associated with Local Number > > Portability) to determine ownership of an E.164 number, hence use of > > ENUM for this purpose alone, will be unnecessary. > > > > To be clear, I believe that providing access via Infrastructure ENUM > > to LNP information may be very helpful; but only if Infrastructure > > ENUM provides more than just this. > > If an Infrastructure ENUM query can combine (a) determination of the > > entity providing service to the destination, (b) determination of the > > corresponding LRN, if one exists, and (c) mapping of the routable > > number (either the number originally indicated, or the LRN) to a Layer > > 5 "point of ingress" specified by the entity providing service to the > > destination; then Infrastructure ENUM is quite a handy mechanism. If > > all it does is (a) then I don't need it. > > > > But in the end this is neither here nor there. I am not wedded to any > > specific technology, I just need workable solutions to real business > > problems. > > > > Tim > > > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, May 24, 2006 4:38 PM > > To: timothy.dwight@verizon.com; timothy.dwight@verizon.com; Michael > > Hammer (mhammer); Brian Rosen; Francois D. Menard; Khan, Sohel Q > > [CTO]; David Meyer; speermint@ietf.org > > Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF > > - SF > > > > Tim, > > > > thanx for your reply, you are raising some important issues. > > Since it is already midnight here, I will reply to it in detail > > tomorrow > > > > I am also working on a more detailed analysis and a draft which will > > require even some more time. > > > > Just a quick one: > > > > >In some parts of the world the function provided by "option > > 2" usage of > > >Infrastructure ENUM could be achieved in other ways (e.g., > > the LERG and > > >NPDB in North America) so in those cases Infrastructure ENUM > > might be a > > >superfluous concept; but if that's the right technical > > answer so be it. > > > > Yes and no ;-) > > You are mixing up here the Registry and the ENUM DNS. > > The Registry is the LERG and NPDB (or is derived from), the ENUM DNS > > is the equivalent on IP of the SCP in the PSTN where the date is > > downloaded to. > > > > Richard > > > > > > ________________________________ > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > Gesendet: Mi 24.05.2006 23:00 > > An: Stastny Richard; timothy.dwight@verizon.com; 'Michael Hammer > > (mhammer)'; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q > > [CTO]'; 'David Meyer'; speermint@ietf.org > > Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF > > - SF > > > > > > > > Richard, > > > > Thank you for the clarification. I understand the distinction you are > > making. > > > > My objective is to be able to translate a destination identifier > > (E.164 number of alphanumeric AoR) into the address of a Layer 5 > > entity designated by the organization providing service to the called > > party. With infrastructure/carrier ENUM I could do this (as described > > in your Option 1), but because ENUM is specific to E.164 numbers it > > would only work for E.164 -formatted destination identifiers. > > > > In pictures, your Option 2 seems to me to imply the following: > > > > +----------------+ +----------+ > > E.164 | infrastructure | serving | identify > > | network > > ingress > > destination -->| ENUM |---> carrier --->| ingress > > |---> point > > specified > > identifier | (option 2) | identity | point | by > > serving carrier > > +----------------+ ^ +----------+ > > | > > +----------------+ | > > non-E.164 | map domain in | | > > Destination -->| URI to carrier |--------+ > > Identifier | identity | > > +----------------+ > > > > In some parts of the world the function provided by "option 2" usage > > of Infrastructure ENUM could be achieved in other ways (e.g., the LERG > > and NPDB in North America) so in those cases Infrastructure ENUM might > > be a superfluous concept; but if that's the right technical answer so > > be it. > > > > The "identify ingress point" function would need to be defined. I > > would like it to consider the specified destination (in addition to > > the carrier providing service to that destination); and I would like > > the procedures to be such that the serving carrier controls (in a > > reasonably dynamic > > way) the point at which traffic destined to a particular destination, > > enters his network. If those requirements can be met, I think this > > approach is workable. > > > > Its biggest drawback is that it precludes a solution ("option 1" usage > > of Infrastructure ENUM) that is sufficient for the majority of today's > > needs. > > It optimizes for a problem that will exist in the future at the > > expense of solving problems that exist today. I realize that solving > > today's problems may not be SPEERMINT's focus, or (arguably) even > > within its charter, but I would hate to see recommendations from > > SPEERMINT preclude or significantly delay solving them. > > > > Suppose we did something like this: > > > > +----------+ [pseudo +----------------+ > > non-E.164 | identify | or real] | infrastructure > > | network > > ingress > > destination -->| "pseudo" |---> E.164 --->| ENUM > > |---> point > > specified > > identifier | E.164 | number | (option 1) | by > > serving carrier > > +----------+ +----------------+ > > > > We could let the ENUM working group define Infrastructure ENUM as > > described in your Option 1 (which is as you know already commercially > > available from a few sources) and SPEERMINT could define the "identify > > pseudo E.164" function that in my diagram feeds into it. This > > function might be as simple as mapping the domain part of the URI to > > an E.164 number uniquely associated with the network providing service > > to the specified destination. Unless this is a lot harder than it > > seems, this shouldn't keep us busy too long :-) > > > > > > Tim > > > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, May 24, 2006 11:16 AM > > To: timothy.dwight@verizon.com; Michael Hammer (mhammer); > > Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David > > Meyer; speermint@ietf.org > > Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture - > > LF - OF - SF > > > > Tim, > > > > >> ... the basic idea of Infrastructure ENUM (which will be used for > > >> service providers is to provide a domain name in a SIP URI =3D a > > >> service provider ID > > >(SPID) > > > > >At the risk of asking an off-topic question (realizing that > > ENUM is not > > >within scope for SPEERMINT), can I ask where the idea that > > >Infrastructure ENUM queries return SPIDs, comes from? It is > > my intent > > >to provide a point of interconnection to be used by the requesting > > >entity to hand to me a call to the specified number. I do > > not intend > > >that the only meaningful part of the URI returned from the > > ENUM query, > > >be > > the domain name. > > > > thank you for raising this important point. I tried to raise > > this some time ago, but got no clear answer > > > > Currently there exist two lines of thought about the usage of > > Infrastructure (and also Carrier ENUM in private trees) > > > > 1. Put in ENUM the ingress point(s) e.g. > > sip:+43xxxx@sbc4711.provider.net 2. > > Put in ENUM the AoR only: e.g. sip:+43xxx@provider.net > > (provider.net is what I meant with SPID) > > > > Most currently prefer option 1, especially in private ENUM trees. > > > > IMHO this is the wrong approach: > > > > There should be a clear separation (and it is in the charter) > > between ENUM and SPEERMINT SPEERMINT peering MUST be able to > > work standalone and without ENUM. > > > > Option 1 assumes also that the user is entering ALWAYS an > > E.164 number as identifier. > > > > But what if he is entering an AoR? > > > > SPEEMINT peering MUST be able to resolve this too so you need > > to find the ingress point independant of ENUM e.g. via RFC3263. > > > > If this MUST be possible, why not enter in (any) ENUM just > > the AoR, if you must be able to resolve the AoR anyway? > > > > Otherwise you need to manage two mappings separate 1. the > > E.164 to ingress point 2. the AoR mapping to ingress point > > > > this is not a good idea > > > > This is the reason why I would prefer to enter in ENUM AoRs > > only the user part in ENUM is always the E.164 number (for > > privacy reasons) the domain part is the SPID, which is mapped > > later to find the ingress point > > > > the calling user may then also use an alis AoR such as > > sip:name@provider.net > > > > regards > > > > Richard > > > > > > > > ________________________________ > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > Gesendet: Mi 24.05.2006 16:46 > > An: Stastny Richard; 'Michael Hammer (mhammer)'; 'Brian > > Rosen'; 'Francois D. > > Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; speermint@ietf.org > > Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - > > LF - OF - SF > > > > > > > > Stastny, Richard said: > > > > > ... the basic idea of Infrastructure ENUM (which will be used for > > > service providers is to provide a domain name in a SIP URI > > =3D a service > > > provider ID > > (SPID) > > > > At the risk of asking an off-topic question (realizing that > > ENUM is not within scope for SPEERMINT), can I ask where the > > idea that Infrastructure ENUM queries return SPIDs, comes > > from? It is my intent to provide a point of interconnection > > to be used by the requesting entity to hand to me a call to > > the specified number. I do not intend that the only > > meaningful part of the URI returned from the ENUM query, be > > the domain name. > > > > tim > > > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu May 25 17:00:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjMwb-0003hK-A4; Thu, 25 May 2006 17:00:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjMwa-0003hC-Ch for speermint@ietf.org; Thu, 25 May 2006 17:00:32 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjMwZ-0007Oh-F4 for speermint@ietf.org; Thu, 25 May 2006 17:00:32 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 25 May 2006 14:00:30 -0700 X-IronPort-AV: i="4.05,173,1146466800"; d="scan'208"; a="549282833:sNHT53672808" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Location Function in SPEERMINT Date: Thu, 25 May 2006 17:00:28 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804652CD6@proton.jnpr.net> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4A77@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Location Function in SPEERMINT Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAATumxgAG4BNwABEZoVAADQ2DIAAC1z/9AAGrFeAACZ2pfQABju7wACHfcEAAAbB9IAAK1HH6AAC9BtAAAGOAdAAAMvVg From: "Reinaldo Penno" To: "Stastny Richard" , , "Michael Hammer \(mhammer\)" , , "Brian Rosen" , "Francois D. Menard" , "Khan, Sohel Q [CTO]" , "David Meyer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3077fcbbd2d4a1504dfa044ebcf773 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I believe it is enough. You could refine it but I might sure of the benefits. Maybe this problem was already solved somewhere and I'm not aware.=20 For example, The UAs would care. >From RFC3263 ;; Priority Weight Port Target IN SRV 0 1 5060 server1.example.com IN SRV 0 2 5060 server2.example.com This tells you the SIP proxy to be contacted. It does not tell you if this the closest Sip Proxy handling @example.com users. It also does not tell you if it is the closest proxy to the callee. In the case of a carriers providing VoIP service to a user, if this provider A peers with provider B in two different locations, which one to choose to send to forward the call? Regards, Reinaldo > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, May 25, 2006 1:52 PM > To: Reinaldo Penno; timothy.dwight@verizon.com; Michael Hammer (mhammer); > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, Sohel Q > [CTO]; David Meyer; speermint@ietf.org > Subject: Re: [Speermint] Location Function in SPEERMINT >=20 > Reinaldo said: > >That's maybe one of the most important issues. This could be complicated > >by the geographically dispersed networks with several entry points. > >Although this might be an interesting problem it might be a rathole. >=20 > So you say RFC 3263 is not enough, something is missing? > e.g. the geographic location of originating and terminating --- what? >=20 > -SIP proxy? who cares > -SBC? > -UA? >=20 > So we are again dealing with SBCs, in this case the geo-location of these > -- rats, holes ;-) >=20 > Richard >=20 >=20 > ________________________________ >=20 > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Do 25.05.2006 22:37 > An: Stastny Richard; timothy.dwight@verizon.com; Michael Hammer (mhammer); > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, Sohel Q > [CTO]; David Meyer; speermint@ietf.org > Betreff: RE: [Speermint] Location Function in SPEERMINT >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, May 25, 2006 1:26 PM > > To: timothy.dwight@verizon.com; Michael Hammer (mhammer); > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > Sohel Q > > [CTO]; David Meyer; speermint@ietf.org > > Subject: [Speermint] Location Function in SPEERMINT > > > > Hi all, > > > > sorry, but I am only able to reply with a short statement, because I > am > > on vacation and have only limited time and bandwitdh (GPRS) > > > > First, I consider this discussion regarding Infrastructure ENUM, LERG > and > > LNP > > important, but in the wrong WG. It should be discussed in ENUM. WG and > > not in SPEERMINT > > > > SPEERMINT is only dealing with Call Routing Data (CRD), which is > defined > > as the OUTPUT of ENUM or some other means. > > > > This implies, that the location function (LF) defined in the > > achitecture draft happens AFTER an ENUM query and therefore > > cannot be the part of the LF. > > > > The LF can only involve the location of the destination "network" > > as defined in SPEERMINT by the use of CRD (which > > is basically a SIP URI because we are currently talking only SIP > > in SPEERMINT) > > > > Of course SPEERMINT needs to define what it considers CRD, > > and AoR or the ingress point of a network. > > > > BUT then SPEERMINT needs also to define how the ingress > > point of a "network" is LOCATED given a SIP AoR. > [[Reinaldo]] >=20 > That's maybe one of the most important issues. This could be complicated > by the geographically dispersed networks with several entry points. > Although this might be an interesting problem it might be a rathole. >=20 >=20 > > > > Richard > > > > > > ________________________________ > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > Gesendet: Do 25.05.2006 20:17 > > An: 'Michael Hammer (mhammer)'; timothy.dwight@verizon.com; Stastny > > Richard; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; > > 'David Meyer'; speermint@ietf.org > > Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF > - SF > > > > > > > > Michael Hammer said: > > > > > Tim, > > > > > > The LERG and LNP databases are intrinsically tied to the operation > of > > the > > TDM > > > infrastructure. Any design that perpatuates these systems when > their > > reason > > > for being (TDM) goes away is a faulty design. > > > > OK with me. I only meant to point out that right now I have these > > capabilities, so recreating them isn't a high priority. > > > > > > > > > > DNS and ENUM provides the equivalent information and mechanisms to > do > > what > > is > > > needed in the IP domain. As such, a design that makes dependencies > on > > legacy > > > systems is deficient. I wouldn't support such a kludge. > > > > Fine. > > > > I'm a big fan of IP-domain solutions. Specifically Infrastructure > ENUM > > looks really handy; my point before was that it's moreso when used in > what > > Richard called "option 1". The alternative ("option 2") only > replicates > > the > > "kludge" to which I already have access. > > > > And to be fair to Richard, he did point out (subtly) that the latter > claim > > is a bit myopic. There are existing means by which VSPs can gain > access > > to > > number portability information relative to national destinations. > They > > don't have such access, at least not easily and not universally, to > number > > portability information relative to international destinations. If > that > > could be provided by Infrastructure ENUM (either "option 1" or "option > 2") > > it would be useful and would not simply replicate existing > capabilities. > > > > Bottom line, both options defined by Richard, would add value. Option > 1 > > adds more value but is specific to destinations identified by E.164 > > numbers > > or URIs with imbedded E.164 numbers. Which is the problem closest to > > hand. > > > > > > > > > > That said, if there are backward compatibilities during the > transition, > > where > > > some information just happens to be known by external systems, such > as > > you > > suggest > > > below, I don't see that as a problem. I am just wary of ending up > with > > two > > > systems in the end when one would do. > > > > Isn't it inevitable that for some time, both will exist? Just as the > GSTN > > and VoIP will coexist for some time, so will their supporting > > infrastructure. > > > > Don't get me wrong. I'm not saying "because I have an SS7 -based > solution > > to LNP I don't need an IP -based solution". All I'm saying is that > when > > given the option of using Infrastructure ENUM to recreate (and in the > case > > of international destinations, extend) the capability I already have, > and > > using it to do that and more, I'm inclined to prefer the latter. > > > > > > > > > > Mike > > > > > > > -----Original Message----- > > > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > Sent: Wednesday, May 24, 2006 6:19 PM > > > To: 'Stastny Richard'; timothy.dwight@verizon.com; > > > timothy.dwight@verizon.com; Michael Hammer (mhammer); 'Brian Rosen'; > > > 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; > > > speermint@ietf.org > > > Subject: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - > OF > > > - SF > > > > > > Richard, > > > > > > Yes I know I was mixing data and mechanism-to-access-data. > > > Still I believe the major point to be correct. In many parts of the > > > world there are already mechanisms (associated with Local Number > > > Portability) to determine ownership of an E.164 number, hence use of > > > ENUM for this purpose alone, will be unnecessary. > > > > > > To be clear, I believe that providing access via Infrastructure ENUM > > > to LNP information may be very helpful; but only if Infrastructure > > > ENUM provides more than just this. > > > If an Infrastructure ENUM query can combine (a) determination of > the > > > entity providing service to the destination, (b) determination of > the > > > corresponding LRN, if one exists, and (c) mapping of the routable > > > number (either the number originally indicated, or the LRN) to a > Layer > > > 5 "point of ingress" specified by the entity providing service to > the > > > destination; then Infrastructure ENUM is quite a handy mechanism. > If > > > all it does is (a) then I don't need it. > > > > > > But in the end this is neither here nor there. I am not wedded to > any > > > specific technology, I just need workable solutions to real business > > > problems. > > > > > > Tim > > > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, May 24, 2006 4:38 PM > > > To: timothy.dwight@verizon.com; timothy.dwight@verizon.com; Michael > > > Hammer (mhammer); Brian Rosen; Francois D. Menard; Khan, Sohel Q > > > [CTO]; David Meyer; speermint@ietf.org > > > Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture - LF - > OF > > > - SF > > > > > > Tim, > > > > > > thanx for your reply, you are raising some important issues. > > > Since it is already midnight here, I will reply to it in detail > > > tomorrow > > > > > > I am also working on a more detailed analysis and a draft which will > > > require even some more time. > > > > > > Just a quick one: > > > > > > >In some parts of the world the function provided by "option > > > 2" usage of > > > >Infrastructure ENUM could be achieved in other ways (e.g., > > > the LERG and > > > >NPDB in North America) so in those cases Infrastructure ENUM > > > might be a > > > >superfluous concept; but if that's the right technical > > > answer so be it. > > > > > > Yes and no ;-) > > > You are mixing up here the Registry and the ENUM DNS. > > > The Registry is the LERG and NPDB (or is derived from), the ENUM DNS > > > is the equivalent on IP of the SCP in the PSTN where the date is > > > downloaded to. > > > > > > Richard > > > > > > > > > ________________________________ > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > Gesendet: Mi 24.05.2006 23:00 > > > An: Stastny Richard; timothy.dwight@verizon.com; 'Michael Hammer > > > (mhammer)'; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q > > > [CTO]'; 'David Meyer'; speermint@ietf.org > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - > OF > > > - SF > > > > > > > > > > > > Richard, > > > > > > Thank you for the clarification. I understand the distinction you > are > > > making. > > > > > > My objective is to be able to translate a destination identifier > > > (E.164 number of alphanumeric AoR) into the address of a Layer 5 > > > entity designated by the organization providing service to the > called > > > party. With infrastructure/carrier ENUM I could do this (as > described > > > in your Option 1), but because ENUM is specific to E.164 numbers it > > > would only work for E.164 -formatted destination identifiers. > > > > > > In pictures, your Option 2 seems to me to imply the following: > > > > > > +----------------+ +----------+ > > > E.164 | infrastructure | serving | identify > > > | network > > > ingress > > > destination -->| ENUM |---> carrier --->| ingress > > > |---> point > > > specified > > > identifier | (option 2) | identity | point | > by > > > serving carrier > > > +----------------+ ^ +----------+ > > > | > > > +----------------+ | > > > non-E.164 | map domain in | | > > > Destination -->| URI to carrier |--------+ > > > Identifier | identity | > > > +----------------+ > > > > > > In some parts of the world the function provided by "option 2" usage > > > of Infrastructure ENUM could be achieved in other ways (e.g., the > LERG > > > and NPDB in North America) so in those cases Infrastructure ENUM > might > > > be a superfluous concept; but if that's the right technical answer > so > > > be it. > > > > > > The "identify ingress point" function would need to be defined. I > > > would like it to consider the specified destination (in addition to > > > the carrier providing service to that destination); and I would like > > > the procedures to be such that the serving carrier controls (in a > > > reasonably dynamic > > > way) the point at which traffic destined to a particular > destination, > > > enters his network. If those requirements can be met, I think this > > > approach is workable. > > > > > > Its biggest drawback is that it precludes a solution ("option 1" > usage > > > of Infrastructure ENUM) that is sufficient for the majority of > today's > > > needs. > > > It optimizes for a problem that will exist in the future at the > > > expense of solving problems that exist today. I realize that > solving > > > today's problems may not be SPEERMINT's focus, or (arguably) even > > > within its charter, but I would hate to see recommendations from > > > SPEERMINT preclude or significantly delay solving them. > > > > > > Suppose we did something like this: > > > > > > +----------+ [pseudo +----------------+ > > > non-E.164 | identify | or real] | infrastructure > > > | network > > > ingress > > > destination -->| "pseudo" |---> E.164 --->| ENUM > > > |---> point > > > specified > > > identifier | E.164 | number | (option 1) | > by > > > serving carrier > > > +----------+ +----------------+ > > > > > > We could let the ENUM working group define Infrastructure ENUM as > > > described in your Option 1 (which is as you know already > commercially > > > available from a few sources) and SPEERMINT could define the > "identify > > > pseudo E.164" function that in my diagram feeds into it. This > > > function might be as simple as mapping the domain part of the URI to > > > an E.164 number uniquely associated with the network providing > service > > > to the specified destination. Unless this is a lot harder than it > > > seems, this shouldn't keep us busy too long :-) > > > > > > > > > Tim > > > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, May 24, 2006 11:16 AM > > > To: timothy.dwight@verizon.com; Michael Hammer (mhammer); > > > Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David > > > Meyer; speermint@ietf.org > > > Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture - > > > LF - OF - SF > > > > > > Tim, > > > > > > >> ... the basic idea of Infrastructure ENUM (which will be used for > > > >> service providers is to provide a domain name in a SIP URI =3D = a > > > >> service provider ID > > > >(SPID) > > > > > > >At the risk of asking an off-topic question (realizing that > > > ENUM is not > > > >within scope for SPEERMINT), can I ask where the idea that > > > >Infrastructure ENUM queries return SPIDs, comes from? It is > > > my intent > > > >to provide a point of interconnection to be used by the requesting > > > >entity to hand to me a call to the specified number. I do > > > not intend > > > >that the only meaningful part of the URI returned from the > > > ENUM query, > > > >be > > > the domain name. > > > > > > thank you for raising this important point. I tried to raise > > > this some time ago, but got no clear answer > > > > > > Currently there exist two lines of thought about the usage of > > > Infrastructure (and also Carrier ENUM in private trees) > > > > > > 1. Put in ENUM the ingress point(s) e.g. > > > sip:+43xxxx@sbc4711.provider.net 2. > > > Put in ENUM the AoR only: e.g. sip:+43xxx@provider.net > > > (provider.net is what I meant with SPID) > > > > > > Most currently prefer option 1, especially in private ENUM trees. > > > > > > IMHO this is the wrong approach: > > > > > > There should be a clear separation (and it is in the charter) > > > between ENUM and SPEERMINT SPEERMINT peering MUST be able to > > > work standalone and without ENUM. > > > > > > Option 1 assumes also that the user is entering ALWAYS an > > > E.164 number as identifier. > > > > > > But what if he is entering an AoR? > > > > > > SPEEMINT peering MUST be able to resolve this too so you need > > > to find the ingress point independant of ENUM e.g. via RFC3263. > > > > > > If this MUST be possible, why not enter in (any) ENUM just > > > the AoR, if you must be able to resolve the AoR anyway? > > > > > > Otherwise you need to manage two mappings separate 1. the > > > E.164 to ingress point 2. the AoR mapping to ingress point > > > > > > this is not a good idea > > > > > > This is the reason why I would prefer to enter in ENUM AoRs > > > only the user part in ENUM is always the E.164 number (for > > > privacy reasons) the domain part is the SPID, which is mapped > > > later to find the ingress point > > > > > > the calling user may then also use an alis AoR such as > > > sip:name@provider.net > > > > > > regards > > > > > > Richard > > > > > > > > > > > > ________________________________ > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > Gesendet: Mi 24.05.2006 16:46 > > > An: Stastny Richard; 'Michael Hammer (mhammer)'; 'Brian > > > Rosen'; 'Francois D. > > > Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; speermint@ietf.org > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - > > > LF - OF - SF > > > > > > > > > > > > Stastny, Richard said: > > > > > > > ... the basic idea of Infrastructure ENUM (which will be used for > > > > service providers is to provide a domain name in a SIP URI > > > =3D a service > > > > provider ID > > > (SPID) > > > > > > At the risk of asking an off-topic question (realizing that > > > ENUM is not within scope for SPEERMINT), can I ask where the > > > idea that Infrastructure ENUM queries return SPIDs, comes > > > from? It is my intent to provide a point of interconnection > > > to be used by the requesting entity to hand to me a call to > > > the specified number. I do not intend that the only > > > meaningful part of the URI returned from the ENUM query, be > > > the domain name. > > > > > > tim > > > > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu May 25 17:10:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjN62-0002kz-R7; Thu, 25 May 2006 17:10:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjN62-0002iN-3N for speermint@ietf.org; Thu, 25 May 2006 17:10:18 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjN60-0008GW-I7 for speermint@ietf.org; Thu, 25 May 2006 17:10:18 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FjN5O-0006M4-3h; Thu, 25 May 2006 16:09:42 -0500 From: "Brian Rosen" To: "'James McEachern'" , "'Stastny Richard'" , "'Francois D. Menard'" , Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Thu, 25 May 2006 17:09:40 -0400 Message-ID: <00e001c6803f$8ce3c470$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAANiSfAAGpkGwABFyNDAABcvUoAAA7iiQAELeetAAAMAqIA== X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Give me an argument about why all of what is called "core sip" in hitchhiker's guide is not in this list? This would be: RFC 3261: The Session Initiation Protocol=20 RFC 3263: Locating SIP Servers=20 RFC 3265: SIP-Specific Event Notification=20 RFC 3323: A Privacy Mechanism for the Session Initiation Protocol (SIP) RFC 3325: Private Extensions to SIP for Asserted Identity within Trusted Networks=20 RFC 3327: SIP Extension Header Field for Registering Non-Adjacent Contacts RFC 3581: An Extension to SIP for Symmetric Response Routing=20 RFC 4320: Actions Addressing Issues Identified with the Non-INVITE Transaction in SIP RFC XXXX: Enhancements for Authenticated Identity Management in SIP aka "SIP Identity" RFC XXXX: Obtaining and Using Globally Routable User Agent Identifiers (GRUU) in SIP (S)=20 RFC XXXX: Managing Client Initiated Connections through SIP aka "SIP outbound" Possibly GRUU doesn't need to be there, although I suspect it does. I think we also have ENUM, PRACK, UPDATE, Reason, and probably a few = others. -----Original Message----- From: James McEachern [mailto:jmce@nortel.com]=20 Sent: Thursday, May 25, 2006 3:27 PM To: Stastny Richard; Francois D. Menard; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture The original proposal that Francois made was that the minimum set of = RFCs was "SIP + RFC 3323 and RFC 3325". It appears that RFC 3323 has been dropped from this list, but I don't recall seeing why. Have I missed something? Jim -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Wednesday, May 24, 2006 7:34 AM To: Francois D. Menard; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >Yes, and presentation restriction, >So 3261, 3263, 3325 and 3326. >Sold! Bought! ;-) If anybody has any additions to this (for minimum requirements), he may holler IMHO in addition a BCP on the population of the header fields, particularly in context with phone numbers (e.164 and non-E.164) is required. A BCP on how to establish two-way TLS may also be useful Richard ________________________________ Von: Francois D. Menard [mailto:fmenard@xittelecom.com] Gesendet: Mi 24.05.2006 13:03 An: Stastny Richard Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Yes, and presentation restriction, So 3261, 3263, 3325 and 3326. Sold! F. -- Fran=E7ois D. M=E9nard Charg=E9 de projet Xit t=E9l=E9com inc. 1350 rue Royale #800 Trois-Rivi=E8res, QC, G9A 4J4 Canada fmenard@xittelecom.com Tel: (819) 374-2556 ext. 268 Fax: (819) 374-0395 Cell: (819) 692-1383 -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: 24 mai 2006 04:19 To: Michael Hammer (mhammer); Brian Rosen; Francois D. Menard; Khan, = Sohel Q [CTO]; David Meyer; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > A least common denominator set will likely be small, but perhaps not > sufficiently rich for any two wishing to peering. > e.g. RFC3261 and 3263 ;-) plus TLS and one kind of asserted identity additional richness could be provided by policy records Richard > Mike > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Tuesday, May 23, 2006 4:54 PM > > To: Michael Hammer (mhammer); Brian Rosen; Francois D. > > Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > >I think the the interworking of SIP to PSTN is out of scope here. > > > > Yes > > I did not find anything about this in the charter. > > It is not even mentioned in the out-of-scope section (which mentions > > at least H.323 ;-) > > > > >While coloring within those lines, the next question is > > whether there > > >is a single subset that can be defined or whether there will > > be many. > > >I am betting on many, probably a different set for each > > federation or > > >even bilateral pairing that might exist. > > > > I always had the idea that we could define minimum requrements > > (which could be the overlap of the many subsets) but maybe I am > > asking too much Or is SIP already as baroque at OSI FTAM was? > > (where we could only find bilateral "peerings" between DEC, IBM and > > Siemens, but not a subset with worked with all three ;-) > > > > Richard > > > > > > ________________________________ > > > > Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Gesendet: Di 23.05.2006 22:32 > > An: Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David > > Meyer; speermint@ietf.org > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > > > > > Brian, > > > > I think the the interworking of SIP to PSTN is out of scope here.=20 > > The issue is whether two peers, once they have discovered each > > other, can know what subset of SIP they need to support. I don't > > think there is any need to go down the rabbit hole on what > > applications are supported and whether they are PSTN emulations or > > simulations or whatever. We may know in the back of our mind that > > some application won't work if RFC X is not supported, but we don't > > need to discuss that. > > We need only to focus on what SIP RFCs are needed on the SIP peer > > interface. > > > > While coloring within those lines, the next question is whether > > there is a single subset that can be defined or whether there will > > be many. I am betting on many, probably a different set for each > > federation or even bilateral pairing that might exist. That could > > be another rabbit hole. > > I would be happy if two peers could point to the same subset and > > agree to use it, no matter how many subsets might exist. > > > > Mike > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Tuesday, May 23, 2006 3:05 PM > > > To: 'Francois D. Menard'; Michael Hammer (mhammer); 'Khan, Sohel Q > > > [CTO]'; 'David Meyer'; speermint@ietf.org > > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering > > Architecture > > > > > > By far the largest mistake EVER made by the IETF in the > > development of > > > SIP was to allow SIP to be extended to imitate the existing > > PSTN. If > > > we ever were to start again, the golden rule would be DON'T IMITATE > > > THE PSTN, and the corollary would be "Just because the PSTN does it > > > that way DOES NOT MEAN it's a good idea". > > > > > > So, the very idea that "replication of functionality in the > > > SS7 minimum message set" is the definition of what we need > > to do makes > > > me want to puke. > > > > > > No, and a pox on your houses for even thinking that. > > > > > > While we're going to start with "basic call", we need to > > define those > > > call features that must cross domain boundaries. > > > Most of them have existing SIP messaging (in sip-examples, for > > > instance). We need to make sure those features work across the > > > boundary. That has nothing whatsoever to do with an SS7 > > message. The > > > mms might give us clues on what features might be > > interesting to put > > > on our list, but I'll bet we end up with a lot less of them, and a > > > bunch of stuff not in SS7 (or C7); inter-domain presence, > > for example. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > > > Sent: Tuesday, May 23, 2006 2:50 PM > > > To: 'Michael Hammer (mhammer)'; 'Khan, Sohel Q [CTO]'; > > 'David Meyer'; > > > speermint@ietf.org > > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering > > Architecture > > > > > > > I don't see anything diametrically opposed between what I > > suggested > > > > and > > > what you are suggesting. > > > > > > I would be satisfied with this: > > > > > > SPEERMINT compliance requires replication of the functionality > > > available in the SS7 minumum message set which can be done by SIP, > > > 3323, 3325. Better than SS7 mms functionlality made possible with > > > ATIS, IP Sphere or other sip profiles will also be considered as > > > SPEERMIT compliant. > > > > > > > If there is to be an IETF-approved SIP profile, I think it should > > > > first be > > > decided if that is the turf of the Speermint or the SIP WG. > > > Those last two statements are at the heart of my concerns. > > > > > > SPEERMINT will be completely toothless as an RFC if it just states, > > > compliance with SPEERMINT can be achieved by compliance > > with non-IETF > > > standards. > > > > > > F. > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu May 25 22:51:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjSQ6-0001aD-9U; Thu, 25 May 2006 22:51:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjSQ5-0001WL-Fw for speermint@ietf.org; Thu, 25 May 2006 22:51:21 -0400 Received: from [205.151.208.34] (helo=fw.tr.xittelecom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjSQ2-0005x1-Uo for speermint@ietf.org; Thu, 25 May 2006 22:51:21 -0400 Received: from [192.168.2.139] (helo=gestionfm) by fw.tr.xittelecom.com with esmtp (Exim 3.36 #1 (Debian)) id 1Fuhg6-0002Kz-00; Sun, 25 Jun 2006 23:22:22 -0400 From: "Francois D. Menard" To: "'James McEachern'" Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Thu, 25 May 2006 22:47:19 -0400 Message-ID: <012701c6806e$b5924de0$8b02a8c0@gestionfm> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAANiSfAAGpkGwABFyNDAABcvUoAAA7iiQAELeetAAD3HUEA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org James, Goof, meant to say 3261, 3323 and 3325 and we can throw in 3263 when = people want to do it with public enum. F.=20 -- Fran=E7ois D. M=E9nard Charg=E9 de projet Xit t=E9l=E9com inc. 1350 rue Royale #800 Trois-Rivi=E8res, QC, G9A 4J4 Canada fmenard@xittelecom.com Tel: (819) 374-2556 ext. 268 Fax: (819) 374-0395 Cell: (819) 692-1383 =20 -----Original Message----- From: James McEachern [mailto:jmce@nortel.com]=20 Sent: 25 mai 2006 15:27 To: Stastny Richard; Francois D. Menard; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture The original proposal that Francois made was that the minimum set of = RFCs was "SIP + RFC 3323 and RFC 3325". It appears that RFC 3323 has been dropped from this list, but I don't recall seeing why. Have I missed something? Jim -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Wednesday, May 24, 2006 7:34 AM To: Francois D. Menard; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >Yes, and presentation restriction, >So 3261, 3263, 3325 and 3326. >Sold! Bought! ;-) If anybody has any additions to this (for minimum requirements), he may holler IMHO in addition a BCP on the population of the header fields, = particularly in context with phone numbers (e.164 and non-E.164) is required. A BCP on how to establish two-way TLS may also be useful Richard ________________________________ Von: Francois D. Menard [mailto:fmenard@xittelecom.com] Gesendet: Mi 24.05.2006 13:03 An: Stastny Richard Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Yes, and presentation restriction, So 3261, 3263, 3325 and 3326. Sold! F. -- Fran=E7ois D. M=E9nard Charg=E9 de projet Xit t=E9l=E9com inc. 1350 rue Royale #800 Trois-Rivi=E8res, QC, G9A 4J4 Canada fmenard@xittelecom.com Tel: (819) 374-2556 ext. 268 Fax: (819) 374-0395 Cell: (819) 692-1383 -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: 24 mai 2006 04:19 To: Michael Hammer (mhammer); Brian Rosen; Francois D. Menard; Khan, = Sohel Q [CTO]; David Meyer; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > A least common denominator set will likely be small, but perhaps not=20 > sufficiently rich for any two wishing to peering. > e.g. RFC3261 and 3263 ;-) plus TLS and one kind of asserted identity additional richness could be provided by policy records Richard > Mike > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Tuesday, May 23, 2006 4:54 PM > > To: Michael Hammer (mhammer); Brian Rosen; Francois D. > > Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > >I think the the interworking of SIP to PSTN is out of scope here. > > > > Yes > > I did not find anything about this in the charter. > > It is not even mentioned in the out-of-scope section (which mentions = > > at least H.323 ;-) > > > > >While coloring within those lines, the next question is > > whether there > > >is a single subset that can be defined or whether there will > > be many. > > >I am betting on many, probably a different set for each > > federation or > > >even bilateral pairing that might exist. > > > > I always had the idea that we could define minimum requrements=20 > > (which could be the overlap of the many subsets) but maybe I am=20 > > asking too much Or is SIP already as baroque at OSI FTAM was? > > (where we could only find bilateral "peerings" between DEC, IBM and=20 > > Siemens, but not a subset with worked with all three ;-) > > > > Richard > > > > > > ________________________________ > > > > Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Gesendet: Di 23.05.2006 22:32 > > An: Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David=20 > > Meyer; speermint@ietf.org > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > > > > > Brian, > > > > I think the the interworking of SIP to PSTN is out of scope here.=20 > > The issue is whether two peers, once they have discovered each=20 > > other, can know what subset of SIP they need to support. I don't=20 > > think there is any need to go down the rabbit hole on what=20 > > applications are supported and whether they are PSTN emulations or=20 > > simulations or whatever. We may know in the back of our mind that=20 > > some application won't work if RFC X is not supported, but we don't=20 > > need to discuss that. > > We need only to focus on what SIP RFCs are needed on the SIP peer=20 > > interface. > > > > While coloring within those lines, the next question is whether=20 > > there is a single subset that can be defined or whether there will=20 > > be many. I am betting on many, probably a different set for each=20 > > federation or even bilateral pairing that might exist. That could=20 > > be another rabbit hole. > > I would be happy if two peers could point to the same subset and=20 > > agree to use it, no matter how many subsets might exist. > > > > Mike > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Tuesday, May 23, 2006 3:05 PM > > > To: 'Francois D. Menard'; Michael Hammer (mhammer); 'Khan, Sohel Q = > > > [CTO]'; 'David Meyer'; speermint@ietf.org > > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering > > Architecture > > > > > > By far the largest mistake EVER made by the IETF in the > > development of > > > SIP was to allow SIP to be extended to imitate the existing > > PSTN. If > > > we ever were to start again, the golden rule would be DON'T IMITATE > > > THE PSTN, and the corollary would be "Just because the PSTN does it > > > that way DOES NOT MEAN it's a good idea". > > > > > > So, the very idea that "replication of functionality in the > > > SS7 minimum message set" is the definition of what we need > > to do makes > > > me want to puke. > > > > > > No, and a pox on your houses for even thinking that. > > > > > > While we're going to start with "basic call", we need to > > define those > > > call features that must cross domain boundaries. > > > Most of them have existing SIP messaging (in sip-examples, for=20 > > > instance). We need to make sure those features work across the=20 > > > boundary. That has nothing whatsoever to do with an SS7 > > message. The > > > mms might give us clues on what features might be > > interesting to put > > > on our list, but I'll bet we end up with a lot less of them, and a = > > > bunch of stuff not in SS7 (or C7); inter-domain presence, > > for example. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > > > Sent: Tuesday, May 23, 2006 2:50 PM > > > To: 'Michael Hammer (mhammer)'; 'Khan, Sohel Q [CTO]'; > > 'David Meyer'; > > > speermint@ietf.org > > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering > > Architecture > > > > > > > I don't see anything diametrically opposed between what I > > suggested > > > > and > > > what you are suggesting. > > > > > > I would be satisfied with this: > > > > > > SPEERMINT compliance requires replication of the functionality=20 > > > available in the SS7 minumum message set which can be done by SIP, = > > > 3323, 3325. Better than SS7 mms functionlality made possible with = > > > ATIS, IP Sphere or other sip profiles will also be considered as=20 > > > SPEERMIT compliant. > > > > > > > If there is to be an IETF-approved SIP profile, I think it should > > > > first be > > > decided if that is the turf of the Speermint or the SIP WG. > > > Those last two statements are at the heart of my concerns. > > > > > > SPEERMINT will be completely toothless as an RFC if it just states, > > > compliance with SPEERMINT can be achieved by compliance > > with non-IETF > > > standards. > > > > > > F. > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu May 25 22:58:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjSXD-0006L3-6H; Thu, 25 May 2006 22:58:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjSXC-0006Ky-2L for speermint@ietf.org; Thu, 25 May 2006 22:58:42 -0400 Received: from [205.151.208.34] (helo=fw.tr.xittelecom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjSXB-0006NF-HB for speermint@ietf.org; Thu, 25 May 2006 22:58:42 -0400 Received: from [192.168.2.139] (helo=gestionfm) by fw.tr.xittelecom.com with esmtp (Exim 3.36 #1 (Debian)) id 1FuhoR-0002LC-00; Sun, 25 Jun 2006 23:30:59 -0400 From: "Francois D. Menard" To: "'Brian Rosen'" , "'James McEachern'" , "'Stastny Richard'" , Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Thu, 25 May 2006 22:55:46 -0400 Message-ID: <012801c6806f$e9ae5780$8b02a8c0@gestionfm> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <00e001c6803f$8ce3c470$640fa8c0@cis.neustar.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAANiSfAAGpkGwABFyNDAABcvUoAAA7iiQAELeetAAAMAqIAAO6n1w X-Spam-Score: 0.0 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org =20 Brian wrote: > Give me an argument about why all of what is called "core sip" in hitchhiker's guide is not in this list? > RFC 3261: The Session Initiation Protocol=20 That is in my list >RFC 3263: Locating SIP Servers=20 That presumes that SIP servers will be discoverable and is thus a = feature beyond the scope of the SS7 MMS which requires manual provisioning of = the interconnection points. > RFC 3265: SIP-Specific Event Notification=20 That's better than the MMS in ISUP? > RFC 3323: A Privacy Mechanism for the Session Initiation Protocol = (SIP) That is in my list > RFC 3325: Private Extensions to SIP for Asserted Identity within Trusted Networks=20 That is in my list > RFC 3327: SIP Extension Header Field for Registering Non-Adjacent Contacts Better than the mms in ISUP thus not needed? > RFC 3581: An Extension to SIP for Symmetric Response Routing=20 Better than the mms in ISUP thus not needed? > RFC 4320: Actions Addressing Issues Identified with the Non-INVITE Transaction in SIP Same.. > RFC XXXX: Enhancements for Authenticated Identity Management in SIP aka "SIP Identity" Same... > RFC XXXX: Obtaining and Using Globally Routable User Agent Identifiers (GRUU) in SIP (S)=20 Same... > RFC XXXX: Managing Client Initiated Connections through SIP aka "SIP outbound" Same... > Possibly GRUU doesn't need to be there, although I suspect it does. Same... > I think we also have ENUM, PRACK, UPDATE, Reason, and probably a few others. Same... F. -----Original Message----- From: James McEachern [mailto:jmce@nortel.com] Sent: Thursday, May 25, 2006 3:27 PM To: Stastny Richard; Francois D. Menard; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture The original proposal that Francois made was that the minimum set of = RFCs was "SIP + RFC 3323 and RFC 3325". It appears that RFC 3323 has been dropped from this list, but I don't recall seeing why. Have I missed something? Jim -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Wednesday, May 24, 2006 7:34 AM To: Francois D. Menard; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >Yes, and presentation restriction, >So 3261, 3263, 3325 and 3326. >Sold! Bought! ;-) If anybody has any additions to this (for minimum requirements), he may holler IMHO in addition a BCP on the population of the header fields, = particularly in context with phone numbers (e.164 and non-E.164) is required. A BCP on how to establish two-way TLS may also be useful Richard ________________________________ Von: Francois D. Menard [mailto:fmenard@xittelecom.com] Gesendet: Mi 24.05.2006 13:03 An: Stastny Richard Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Yes, and presentation restriction, So 3261, 3263, 3325 and 3326. Sold! F. -- Fran=E7ois D. M=E9nard Charg=E9 de projet Xit t=E9l=E9com inc. 1350 rue Royale #800 Trois-Rivi=E8res, QC, G9A 4J4 Canada fmenard@xittelecom.com Tel: (819) 374-2556 ext. 268 Fax: (819) 374-0395 Cell: (819) 692-1383 -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: 24 mai 2006 04:19 To: Michael Hammer (mhammer); Brian Rosen; Francois D. Menard; Khan, = Sohel Q [CTO]; David Meyer; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > A least common denominator set will likely be small, but perhaps not=20 > sufficiently rich for any two wishing to peering. > e.g. RFC3261 and 3263 ;-) plus TLS and one kind of asserted identity additional richness could be provided by policy records Richard > Mike > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Tuesday, May 23, 2006 4:54 PM > > To: Michael Hammer (mhammer); Brian Rosen; Francois D. > > Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > >I think the the interworking of SIP to PSTN is out of scope here. > > > > Yes > > I did not find anything about this in the charter. > > It is not even mentioned in the out-of-scope section (which mentions = > > at least H.323 ;-) > > > > >While coloring within those lines, the next question is > > whether there > > >is a single subset that can be defined or whether there will > > be many. > > >I am betting on many, probably a different set for each > > federation or > > >even bilateral pairing that might exist. > > > > I always had the idea that we could define minimum requrements=20 > > (which could be the overlap of the many subsets) but maybe I am=20 > > asking too much Or is SIP already as baroque at OSI FTAM was? > > (where we could only find bilateral "peerings" between DEC, IBM and=20 > > Siemens, but not a subset with worked with all three ;-) > > > > Richard > > > > > > ________________________________ > > > > Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Gesendet: Di 23.05.2006 22:32 > > An: Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David=20 > > Meyer; speermint@ietf.org > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > > > > > Brian, > > > > I think the the interworking of SIP to PSTN is out of scope here.=20 > > The issue is whether two peers, once they have discovered each=20 > > other, can know what subset of SIP they need to support. I don't=20 > > think there is any need to go down the rabbit hole on what=20 > > applications are supported and whether they are PSTN emulations or=20 > > simulations or whatever. We may know in the back of our mind that=20 > > some application won't work if RFC X is not supported, but we don't=20 > > need to discuss that. > > We need only to focus on what SIP RFCs are needed on the SIP peer=20 > > interface. > > > > While coloring within those lines, the next question is whether=20 > > there is a single subset that can be defined or whether there will=20 > > be many. I am betting on many, probably a different set for each=20 > > federation or even bilateral pairing that might exist. That could=20 > > be another rabbit hole. > > I would be happy if two peers could point to the same subset and=20 > > agree to use it, no matter how many subsets might exist. > > > > Mike > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Tuesday, May 23, 2006 3:05 PM > > > To: 'Francois D. Menard'; Michael Hammer (mhammer); 'Khan, Sohel Q = > > > [CTO]'; 'David Meyer'; speermint@ietf.org > > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering > > Architecture > > > > > > By far the largest mistake EVER made by the IETF in the > > development of > > > SIP was to allow SIP to be extended to imitate the existing > > PSTN. If > > > we ever were to start again, the golden rule would be DON'T IMITATE > > > THE PSTN, and the corollary would be "Just because the PSTN does it > > > that way DOES NOT MEAN it's a good idea". > > > > > > So, the very idea that "replication of functionality in the > > > SS7 minimum message set" is the definition of what we need > > to do makes > > > me want to puke. > > > > > > No, and a pox on your houses for even thinking that. > > > > > > While we're going to start with "basic call", we need to > > define those > > > call features that must cross domain boundaries. > > > Most of them have existing SIP messaging (in sip-examples, for=20 > > > instance). We need to make sure those features work across the=20 > > > boundary. That has nothing whatsoever to do with an SS7 > > message. The > > > mms might give us clues on what features might be > > interesting to put > > > on our list, but I'll bet we end up with a lot less of them, and a = > > > bunch of stuff not in SS7 (or C7); inter-domain presence, > > for example. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > > > Sent: Tuesday, May 23, 2006 2:50 PM > > > To: 'Michael Hammer (mhammer)'; 'Khan, Sohel Q [CTO]'; > > 'David Meyer'; > > > speermint@ietf.org > > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering > > Architecture > > > > > > > I don't see anything diametrically opposed between what I > > suggested > > > > and > > > what you are suggesting. > > > > > > I would be satisfied with this: > > > > > > SPEERMINT compliance requires replication of the functionality=20 > > > available in the SS7 minumum message set which can be done by SIP, = > > > 3323, 3325. Better than SS7 mms functionlality made possible with = > > > ATIS, IP Sphere or other sip profiles will also be considered as=20 > > > SPEERMIT compliant. > > > > > > > If there is to be an IETF-approved SIP profile, I think it should > > > > first be > > > decided if that is the turf of the Speermint or the SIP WG. > > > Those last two statements are at the heart of my concerns. > > > > > > SPEERMINT will be completely toothless as an RFC if it just states, > > > compliance with SPEERMINT can be achieved by compliance > > with non-IETF > > > standards. > > > > > > F. > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 03:18:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjWZm-0005B3-Jd; Fri, 26 May 2006 03:17:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjWZl-0005Ay-NJ for speermint@ietf.org; Fri, 26 May 2006 03:17:37 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FjWZj-0005OK-57 for speermint@ietf.org; Fri, 26 May 2006 03:17:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Fri, 26 May 2006 09:17:31 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A78@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcZ/J15wu/Ba/2sNTLCXUP/3hHYAhQAFEQbgAAESENAAVSI7AQ== From: "Stastny Richard" To: , "Michael Hammer \(mhammer\)" , "Otmar Lendl" X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: "Khan, Sohel Q \[CTO\]" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Henry wrote: >I believe Mike is right on track. Overloading the DNS with application >protocol information, such as detailed policies for SIP is not what the = DNS >was designed for. > >Going further down this path would make the DNS a successor of the AIN! Could you please elaborate a bit more in detail what exeactly you mean with "overloading the DNS"? The root servers? the query types? the clients? specific servers? the = Internet as a whole? =20 Richard -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Wednesday, May 24, 2006 9:22 AM To: Otmar Lendl Cc: Khan, Sohel Q [CTO]; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Otmar, I think our main difference is that I am suspecting that the policy will be large and possibly very dynamic, thus less suitable for locating in DNS. Also, instead of pointing directly to a single policy document, which seems like a one-size-fits-all periodic user poll option,; rather, use Subscriptions where the resulting document may depend on authentication and who is asking, and can be pushed on the schedule of the server when the policy changes. These are just suggestions being thrown out for discussion. I'd like to hear what folks think about them. I'm also questioning how much information about SIP needs to be embedded in other protocols like DNS, DHCP, etc. and how much might be more cohesive if handled via SIP-based mechanisms. Finding the right balance, if you will. Mike > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Wednesday, May 24, 2006 7:44 AM > To: Michael Hammer (mhammer) > Cc: speermint@ietf.org; Khan, Sohel Q [CTO] > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > Michael, > > On 2006/05/24 02:05, "Michael Hammer (mhammer)" > wrote: > > > > I did read one of your drafts, but had doubts about whether > all this > > policy data should be pushed in the DNS. > > Well, if the policy is to big, then the DNS can contain a URL > which points to the large policy. See the last example in > draft-lendl-domain-policy-ddds. > > > I was wondering whether the DNS could be used to discover: > > - that a particular user is served by a particular service > provider, > > Is the user identified by E.164 number or by SIP URI? > > If the latter, then my draft says: > > * either the domain part of the SIP URI is the provider's ID, or > > * a non-terminal NAPTR in the customer's domain points to the > provider's domain where the real policy is stored. > > (if the former, then ENUM is used first) > > > and > > - that service provider has a URI to which the originating SP can > > subscribe to get further information, and > > That fits in nicely with my draft. You just need to define a > policy-type for this subscription information. > > > - that information says the terminating SP can support peering with > > =3D federation subset A, or > > =3D federation subset B, or ... > > Ok; if this list is long, then an external document is fine. > If it is very short, I prefer storing it in the DNS and skip > one step at call setup time. > > If these are just named subsets, then the DNS need only store > the name of the subset and not the list of RFC and BCPs. > > > I suppose that policy document could list all the RFCs you > support and > > then spend time figuring out what matches and what doesn't. But I > > would wonder how well each permutation has been tested. > > That problem is independent of whether you store the > requirement list in the DNS or retrieve it via different means. > > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 05:49:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjYwa-0007uj-NR; Fri, 26 May 2006 05:49:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjYwZ-0007ue-Em for speermint@ietf.org; Fri, 26 May 2006 05:49:19 -0400 Received: from [204.209.140.176] (helo=wodka.aus-biz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjYwV-0002w1-2b for speermint@ietf.org; Fri, 26 May 2006 05:49:19 -0400 Received: from [192.168.1.103] (cpe-24-95-54-117.columbus.res.rr.com [24.95.54.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Duane Groth", Issuer "CAcert Class 3 Root" (not verified)) by wodka.aus-biz.com (Postfix) with ESMTP id 125C925EF; Fri, 26 May 2006 05:49:06 -0400 (EDT) Message-ID: <4476CF0D.8030507@e164.org> Date: Fri, 26 May 2006 05:49:01 -0400 From: Duane User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture References: <32755D354E6B65498C3BD9FD496C7D462C4A78@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4A78@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "Khan, Sohel Q \[CTO\]" , speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Stastny Richard wrote: > Could you please elaborate a bit more in detail what exeactly you mean > with "overloading the DNS"? That's usually a term thrown in by "purists" when they run out of other arguments, we store a lot of information in e164.org other then just SIP and we're no where near overloaded, actually we're heavily under utilised, although I tend to draw the line at storing redundant information (that could be found out from a SIP connection for example) unless there is a good reason otherwise. > The root servers? the query types? the clients? specific servers? the Internet as a whole? If the DNS system is this fragile that it can't cope with another 20 bytes of data (that is only accessed on demand) we should all call it a day and go home :) -- Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://e164.org - Because e164.arpa is a tax on VoIP "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 06:50:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjZt5-0002pW-Jr; Fri, 26 May 2006 06:49:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjZt3-0002pN-Ra for speermint@ietf.org; Fri, 26 May 2006 06:49:45 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjZt2-0000vP-BI for speermint@ietf.org; Fri, 26 May 2006 06:49:45 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 945681A337; Fri, 26 May 2006 12:49:32 +0200 (CEST) Date: Fri, 26 May 2006 12:49:32 +0200 From: Otmar Lendl To: Reinaldo Penno Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Message-ID: <20060526104932.GF1811@nic.at> Mail-Followup-To: Otmar Lendl , Reinaldo Penno , "Michael Hammer (mhammer)" , "Khan, Sohel Q [CTO]" , speermint@ietf.org References: <20060525193612.GE1811@nic.at> <9BD5D7887235424FA97DFC223CAE3C2804652CCC@proton.jnpr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2804652CCC@proton.jnpr.net> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: "Khan, Sohel Q \[CTO\]" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/05/25 22:05, Reinaldo Penno wrote: > Joining in.... Welcome. > I believe your proposal could make sense in some settlement free > (business or otherwise) environment like those VoIP peering points in > Europe. I could also take your proposal even further and argue that > everybody will have a domain name and SIP server at their homes and peer > directly over TLS with the domain to which the call is destined. This > will create a O(n^2) where n is quite large. Indeed. I think we should not design something that does not work in that setting. > My guess is that in reality many ISPs, MSOs and Carries will peer at > specific peering points with well defined rules. I expect that to happen as well. I consider such a peering point incl. its rules as a prime example of a federation. The domain policy DDDS is thus very well suited to tell originating networks at which peering exchanges the destination network is present. > The big players will > provide peering service for the small ones being them enterprise or > otherwise. This would reduce the O(n^2) that you are so worried about. Yes, I can imagine the big players want to do that. On the other hand, the small ones and the enterprises want to avoid them for as many calls as possible. > So, good news, it is already like this. Global carriers already provide > the link and VoIP services for big enterprises. Smaller ISP use big ones > for transit, etc, etc That's the classic hierarchical model of communication. This makes a lot of sense for anything which requires a physical connection, like e.g. L3 traffic. I'm not so sure whether that's the only model if you talk about application layer stuff. Consider e.g. email. There you had X.400 with its hierarchical model and SMTP with its flat "everybody can talk to everybody" model. Which won the quest for world dominance? In the early days of the commercial Internet, a lot of enterprises used their ISPs as mail relay. (That was an unlimted source of joy for me as the postmaster of an ISP) These days almost all enterprise <-> enterprise email will not touch the mailserver of an ISP. Ditto for mails between small ISPs: the layer 3 packets will get handled by backbone operators, but at the SMTP layer they are not involved at all. The same is possible with SIP. Small operators and enterprises can choose to route all their traffic via the SIP servers of bigger operators, or they can choose to bypass those. I can't imagine that the IETF will endorse a solution which takes away that choice. > I bet there will also be tons of consolidation amongst pure VSPs and > many of them will just go chapter 11 when competing with big carriers. > But now we are in the VSP feeding frenzy... The competition between VSPs will look tame compared to what will happen when the carriers have to compete with their own customers. > I also do not follow your example below. It seems you are bundling > several control aspect functions. In the BGP model you establish a TCP > connection with each peer and exchange routing tables. In the TLS model > you also establish one connection with each peer to exchange SIP control > traffic. How's that different? What do you call links? The difference is in the setup. A BGP connection needs manual configuration on both sides. The set of communication endpoints (in this case, layer3) that is reachable via that peering is negotiated *within* that connection. For SIP/TLS, reachability information is not exchanged via the SIP connection. The DNS is used for that. The TLS connection is dynamically established at the first call to the destination domain based on the information in the destination's domain. (RFC3263 NATPR, SRV + A records) TLS is used for authentication and security and SIP is just the means to complete the call and is not a routing protocol. > The only difference between the models (DNS vs. subscription) that you > could argue is what routing people call membership and discovery. What > you say is that discovery and membership is faster with a DNS model. I'm not sure if I can follow you here. > I would argue that in all cases DNS could be used for location (apart > from manual configuration) and in non ad-hoc peering scenarios > subscription provides a quasi instantaneous notification when a peering > policy changes, it does not involve any third party server, and can > carry variable amounts of data, and already possess all security > features existing in SIP. Do I read this correctly that you want a SIP-based routing architecture where reachability information between networks are exchanged via SIP messages? In other words, something like BGP, but instead of L3 routes (connected neworks as identified by CIDR prefixes) this protocol talks about SIP URIs (or SIP domains)? In that case RFC3263 "Locating SIP Servers" (which is purely DNS-based) would be replaced by this SIP-based routing protocol? /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 08:03:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjb2I-0005NU-En; Fri, 26 May 2006 08:03:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjb2G-0005Mk-Nd for speermint@ietf.org; Fri, 26 May 2006 08:03:20 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjb2D-0007QX-46 for speermint@ietf.org; Fri, 26 May 2006 08:03:20 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 26 May 2006 05:03:16 -0700 X-IronPort-AV: i="4.05,176,1146466800"; d="scan'208"; a="549420251:sNHT35547952" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Fri, 26 May 2006 08:03:14 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804652D12@proton.jnpr.net> In-Reply-To: <20060526104932.GF1811@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaAsiMtTfsqtysuQFqTQiMnrZHhDAAB7UIQ From: "Reinaldo Penno" To: "Otmar Lendl" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: "Khan, Sohel Q \[CTO\]" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Friday, May 26, 2006 3:50 AM > To: Reinaldo Penno > Cc: Michael Hammer (mhammer); Khan, Sohel Q [CTO]; speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > On 2006/05/25 22:05, Reinaldo Penno wrote: > > Joining in.... >=20 > Welcome. >=20 > > I believe your proposal could make sense in some settlement free > > (business or otherwise) environment like those VoIP peering points in > > Europe. I could also take your proposal even further and argue that > > everybody will have a domain name and SIP server at their homes and peer > > directly over TLS with the domain to which the call is destined. This > > will create a O(n^2) where n is quite large. >=20 > Indeed. I think we should not design something that does not work in that > setting. >=20 > > My guess is that in reality many ISPs, MSOs and Carries will peer at > > specific peering points with well defined rules. >=20 > I expect that to happen as well. I consider such a peering point incl. > its rules as a prime example of a federation. The domain policy DDDS > is thus very well suited to tell originating networks at which > peering exchanges the destination network is present. >=20 > > The big players will > > provide peering service for the small ones being them enterprise or > > otherwise. This would reduce the O(n^2) that you are so worried about. >=20 > Yes, I can imagine the big players want to do that. On the other hand, the > small ones and the enterprises want to avoid them for as many calls > as possible. >=20 > > So, good news, it is already like this. Global carriers already provide > > the link and VoIP services for big enterprises. Smaller ISP use big ones > > for transit, etc, etc >=20 > That's the classic hierarchical model of communication. >=20 > This makes a lot of sense for anything which requires a physical > connection, like e.g. L3 traffic. >=20 > I'm not so sure whether that's the only model if you talk about > application layer stuff. Consider e.g. email. There you had > X.400 with its hierarchical model and SMTP with its flat > "everybody can talk to everybody" model. >=20 > Which won the quest for world dominance? >=20 > In the early days of the commercial Internet, a lot of enterprises > used their ISPs as mail relay. (That was an unlimted source of > joy for me as the postmaster of an ISP) >=20 > These days almost all enterprise <-> enterprise email will not > touch the mailserver of an ISP. >=20 > Ditto for mails between small ISPs: the layer 3 packets will get handled > by backbone operators, but at the SMTP layer they are not involved at all. >=20 > The same is possible with SIP. Small operators and enterprises > can choose to route all their traffic via the SIP servers of > bigger operators, or they can choose to bypass those. >=20 > I can't imagine that the IETF will endorse a solution which > takes away that choice. >=20 > > I bet there will also be tons of consolidation amongst pure VSPs and > > many of them will just go chapter 11 when competing with big carriers. > > But now we are in the VSP feeding frenzy... >=20 > The competition between VSPs will look tame compared to what will happen > when the carriers have to compete with their own customers. >=20 > > I also do not follow your example below. It seems you are bundling > > several control aspect functions. In the BGP model you establish a TCP > > connection with each peer and exchange routing tables. In the TLS model > > you also establish one connection with each peer to exchange SIP control > > traffic. How's that different? What do you call links? >=20 > The difference is in the setup. >=20 > A BGP connection needs manual configuration on both sides. > The set of communication endpoints (in this case, layer3) that > is reachable via that peering is negotiated *within* that connection. >=20 > For SIP/TLS, reachability information is not exchanged via the > SIP connection.=20 > >The DNS is used for that. [[Reinaldo]]=20 Okay, this is where I believe you are confusing things. DNS is used for _location_ (thus the name of the RFC "Locating SIP Servers"), _not reachability_. Location is _quite_ different than reachability.=20 The only device that can attest reachability to the SIP proxy's IP address provided by a DNS server in a response is a router or a device with similar properties. >=20 > The TLS connection is dynamically established at the first call to the > destination domain based on the information in the destination's domain. > (RFC3263 NATPR, SRV + A records) [[Reinaldo]]=20 Sure. >=20 > TLS is used for authentication and security and SIP is just the means to > complete the call and is not a routing protocol. >=20 > > The only difference between the models (DNS vs. subscription) that you > > could argue is what routing people call membership and discovery. What > > you say is that discovery and membership is faster with a DNS model. >=20 > I'm not sure if I can follow you here. >=20 > > I would argue that in all cases DNS could be used for location (apart > > from manual configuration) and in non ad-hoc peering scenarios > > subscription provides a quasi instantaneous notification when a peering > > policy changes, it does not involve any third party server, and can > > carry variable amounts of data, and already possess all security > > features existing in SIP. >=20 > Do I read this correctly that you want a SIP-based routing architecture > where reachability information between networks are exchanged via > SIP messages? Reachability or location? >=20 > In other words, something like BGP, but instead of L3 routes (connected > neworks as identified by CIDR prefixes) this protocol talks about > SIP URIs (or SIP domains)? >=20 > In that case RFC3263 "Locating SIP Servers" (which is purely DNS-based) > would be replaced by this SIP-based routing protocol >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 09:11:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjc5p-0005iB-Dy; Fri, 26 May 2006 09:11:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjc5o-0005i6-G6 for speermint@ietf.org; Fri, 26 May 2006 09:11:04 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjc5m-0007pN-22 for speermint@ietf.org; Fri, 26 May 2006 09:11:04 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k4QDB1Pu002659 for ; Fri, 26 May 2006 06:11:01 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k4QDB1kd002658 for speermint@ietf.org; Fri, 26 May 2006 06:11:01 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 26 May 2006 06:11:01 -0700 From: David Meyer To: speermint@ietf.org Message-ID: <20060526131101.GA2649@1-4-5.net> Mime-Version: 1.0 User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [Speermint] [ietf-secretariat@ietf.org: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada] X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1284775678==" Errors-To: speermint-bounces@ietf.org --===============1284775678== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable ----- Forwarded message from ietf-secretariat@ietf.org ----- > From: ietf-secretariat@ietf.org > To: ietf-announce@ietf.org > Cc:=20 > Subject: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting > in Montreal, Quebec, Canada=20 > Date: Fri, 26 May 2006 00:00:01 -0400 >=20 >=20 > There are two (2) Internet-Draft cutoff dates for the 66th=20 > IETF Meeting in Montreal, Quebec, Canada: >=20 > June 19th: Cutoff Date for Initial (i.e., version -00)=20 > Internet-Draft Submissions=20 >=20 > All initial Internet-Drafts (version -00) must be submitted by Monday,=20 > June 19th at 9:00 AM ET. As always, all initial submissions with a=20 > filename beginning with "draft-ietf" must be approved by the=20 > appropriate WG Chair before they can be processed or announced. The=20 > Secretariat would appreciate receiving WG Chair approval by Monday,=20 > June 12th at 9:00 AM ET. >=20 > June 26th: Cutoff Date for Revised (i.e., version -01 and higher)=20 > Internet-Draft Submissions=20 >=20 > All revised Internet-Drafts (version -01 and higher) must be submitted=20 > by Monday, June 26th at 9:00 AM ET. >=20 > Initial and revised Internet-Drafts received after their respective=20 > cutoff dates will not be made available in the Internet-Drafts=20 > directory or announced until on or after Monday, July 10th at 9:00=20 > AM ET, when Internet-Draft posting resumes. Please do not wait until=20 > the last minute to submit. >=20 > Thank you for your understanding and cooperation. If you have any=20 > questions or concerns, then please send a message to=20 > internet-drafts@ietf.org. >=20 > The IETF Secretariat >=20 > FYI: The Internet-Draft cutoff dates as well as other significant dates > for the 66th IETF Meeting can be found at http://www.ietf.org/meetings/cu= toff_dates_66.html. >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce ----- End forwarded message ----- --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEdv5lORgD1qCZ2KcRAvoKAJ9qTTRYueKfevkxFlGdH7R/+tB60ACfcP6o KILjS2XhrhyaXZBok+OKKZ4= =5LZs -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- --===============1284775678== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============1284775678==-- From speermint-bounces@ietf.org Fri May 26 09:36:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjcTm-0004y9-Ls; Fri, 26 May 2006 09:35:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjcTl-0004y3-BV for speermint@ietf.org; Fri, 26 May 2006 09:35:49 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjcTk-0000UY-2I for speermint@ietf.org; Fri, 26 May 2006 09:35:49 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id EAAB71A337; Fri, 26 May 2006 15:35:46 +0200 (CEST) Date: Fri, 26 May 2006 15:35:46 +0200 From: Otmar Lendl To: Patrick Melampy Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Message-ID: <20060526133546.GB27495@nic.at> Mail-Followup-To: Otmar Lendl , Patrick Melampy , "'Michael Hammer (mhammer)'" , "'Khan, Sohel Q [CTO]'" , speermint@ietf.org References: <072C5B76F7CEAB488172C6F64B30B5E3017E6597@xmb-rtp-20b.amer.cisco.com> <019c01c67f45$1b30ece0$0202fea9@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <019c01c67f45$1b30ece0$0202fea9@acmepacket.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: "'Khan, Sohel Q \[CTO\]'" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/05/24 17:05, Patrick Melampy wrote: > Subscriptions have other beneficial attributes -- as they can work across > network boundaries and have context. Subscribe/Notify can deliver a policy > that corresponds to a reverse flow of SIP traffic. Plus the Notification can > provide near real time changes. Also very contextual data can be included in > the notification -- providing a nice mechanism for automatic congestion > control. > > I like DNS providing LOCATION only, and I like the notion of all other > attributes that have a contextual base to be delivered in a contextual way. I think I can see your point. I still have a serious problem regarding how to bootstrap such a system as * Carriers seem to hate to expose their SIP ingress elements to the open Internet. They firewall, use private address spaces (e.g. GRX) or otherwise block incoming SIP calls before they reach the SIP stack. * we want to avoid a mandatory bilateral configuration of peerings. Could you sketch how a dynamic peering discovery could work with a SIP subscription model? /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 10:49:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjdcZ-0005Sy-MW; Fri, 26 May 2006 10:48:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjdcY-0005QL-GT for speermint@ietf.org; Fri, 26 May 2006 10:48:58 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjdcX-0002R1-NF for speermint@ietf.org; Fri, 26 May 2006 10:48:58 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k4QEhlu16444; Fri, 26 May 2006 10:43:47 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Location Function in SPEERMINT Date: Fri, 26 May 2006 10:48:48 -0400 Message-ID: In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2804652CD6@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Location Function in SPEERMINT Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAATumxgAG4BNwABEZoVAADQ2DIAAC1z/9AAGrFeAACZ2pfQABju7wACHfcEAAAbB9IAAK1HH6AAC9BtAAAGOAdAAAMvVgACWHGLA= From: "James McEachern" To: "Reinaldo Penno" , "Stastny Richard" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f9ac37b081a3249085c4867ee1404d4 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org >This tells you the SIP proxy to be contacted. It does not tell you if=20 >this the closest Sip Proxy handling @example.com users. It also does=20 >not tell you if it is the closest proxy to the callee. Is the ability to "identify the closest proxy" a requirement for = Speermint? Many people have pointed out that distance is dead, or at = least should be, so it isn't clear to me that we really care. The = Requirements and Terminology draft doesn't explicitly say, but my = reading of section 5.2 implies this is not a requirement.=20 That having been said, I don't necessarily have strong views either way. = I'd just like to be clear on whether or not it is a requirement. Jim -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 Sent: Thursday, May 25, 2006 5:00 PM To: Stastny Richard; timothy.dwight@verizon.com; Michael Hammer = (mhammer); timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; = Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org Subject: RE: [Speermint] Location Function in SPEERMINT I believe it is enough. You could refine it but I might sure of the benefits. Maybe this problem was already solved somewhere and I'm not aware.=20 For example, The UAs would care. >From RFC3263 ;; Priority Weight Port Target IN SRV 0 1 5060 server1.example.com IN SRV 0 2 5060 server2.example.com This tells you the SIP proxy to be contacted. It does not tell you if this the closest Sip Proxy handling @example.com users. It also does not tell you if it is the closest proxy to the callee. In the case of a carriers providing VoIP service to a user, if this provider A peers with provider B in two different locations, which one to choose to send to forward the call? Regards, Reinaldo > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, May 25, 2006 1:52 PM > To: Reinaldo Penno; timothy.dwight@verizon.com; Michael Hammer (mhammer); > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, Sohel Q > [CTO]; David Meyer; speermint@ietf.org > Subject: Re: [Speermint] Location Function in SPEERMINT >=20 > Reinaldo said: > >That's maybe one of the most important issues. This could be complicated > >by the geographically dispersed networks with several entry points. > >Although this might be an interesting problem it might be a rathole. >=20 > So you say RFC 3263 is not enough, something is missing? > e.g. the geographic location of originating and terminating --- what? >=20 > -SIP proxy? who cares > -SBC? > -UA? >=20 > So we are again dealing with SBCs, in this case the geo-location of these > -- rats, holes ;-) >=20 > Richard >=20 >=20 > ________________________________ >=20 > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Do 25.05.2006 22:37 > An: Stastny Richard; timothy.dwight@verizon.com; Michael Hammer (mhammer); > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, Sohel Q > [CTO]; David Meyer; speermint@ietf.org > Betreff: RE: [Speermint] Location Function in SPEERMINT >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, May 25, 2006 1:26 PM > > To: timothy.dwight@verizon.com; Michael Hammer (mhammer); > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > Sohel Q > > [CTO]; David Meyer; speermint@ietf.org > > Subject: [Speermint] Location Function in SPEERMINT > > > > Hi all, > > > > sorry, but I am only able to reply with a short statement, because I > am > > on vacation and have only limited time and bandwitdh (GPRS) > > > > First, I consider this discussion regarding Infrastructure ENUM, LERG > and > > LNP > > important, but in the wrong WG. It should be discussed in ENUM. WG and > > not in SPEERMINT > > > > SPEERMINT is only dealing with Call Routing Data (CRD), which is > defined > > as the OUTPUT of ENUM or some other means. > > > > This implies, that the location function (LF) defined in the > > achitecture draft happens AFTER an ENUM query and therefore > > cannot be the part of the LF. > > > > The LF can only involve the location of the destination "network" > > as defined in SPEERMINT by the use of CRD (which > > is basically a SIP URI because we are currently talking only SIP > > in SPEERMINT) > > > > Of course SPEERMINT needs to define what it considers CRD, > > and AoR or the ingress point of a network. > > > > BUT then SPEERMINT needs also to define how the ingress > > point of a "network" is LOCATED given a SIP AoR. > [[Reinaldo]] >=20 > That's maybe one of the most important issues. This could be complicated > by the geographically dispersed networks with several entry points. > Although this might be an interesting problem it might be a rathole. >=20 >=20 > > > > Richard > > > > > > ________________________________ > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > Gesendet: Do 25.05.2006 20:17 > > An: 'Michael Hammer (mhammer)'; timothy.dwight@verizon.com; Stastny > > Richard; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; > > 'David Meyer'; speermint@ietf.org > > Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF > - SF > > > > > > > > Michael Hammer said: > > > > > Tim, > > > > > > The LERG and LNP databases are intrinsically tied to the operation > of > > the > > TDM > > > infrastructure. Any design that perpatuates these systems when > their > > reason > > > for being (TDM) goes away is a faulty design. > > > > OK with me. I only meant to point out that right now I have these > > capabilities, so recreating them isn't a high priority. > > > > > > > > > > DNS and ENUM provides the equivalent information and mechanisms to > do > > what > > is > > > needed in the IP domain. As such, a design that makes dependencies > on > > legacy > > > systems is deficient. I wouldn't support such a kludge. > > > > Fine. > > > > I'm a big fan of IP-domain solutions. Specifically Infrastructure > ENUM > > looks really handy; my point before was that it's moreso when used in > what > > Richard called "option 1". The alternative ("option 2") only > replicates > > the > > "kludge" to which I already have access. > > > > And to be fair to Richard, he did point out (subtly) that the latter > claim > > is a bit myopic. There are existing means by which VSPs can gain > access > > to > > number portability information relative to national destinations. > They > > don't have such access, at least not easily and not universally, to > number > > portability information relative to international destinations. If > that > > could be provided by Infrastructure ENUM (either "option 1" or "option > 2") > > it would be useful and would not simply replicate existing > capabilities. > > > > Bottom line, both options defined by Richard, would add value. Option > 1 > > adds more value but is specific to destinations identified by E.164 > > numbers > > or URIs with imbedded E.164 numbers. Which is the problem closest to > > hand. > > > > > > > > > > That said, if there are backward compatibilities during the > transition, > > where > > > some information just happens to be known by external systems, such > as > > you > > suggest > > > below, I don't see that as a problem. I am just wary of ending up > with > > two > > > systems in the end when one would do. > > > > Isn't it inevitable that for some time, both will exist? Just as the > GSTN > > and VoIP will coexist for some time, so will their supporting > > infrastructure. > > > > Don't get me wrong. I'm not saying "because I have an SS7 -based > solution > > to LNP I don't need an IP -based solution". All I'm saying is that > when > > given the option of using Infrastructure ENUM to recreate (and in the > case > > of international destinations, extend) the capability I already have, > and > > using it to do that and more, I'm inclined to prefer the latter. > > > > > > > > > > Mike > > > > > > > -----Original Message----- > > > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > Sent: Wednesday, May 24, 2006 6:19 PM > > > To: 'Stastny Richard'; timothy.dwight@verizon.com; > > > timothy.dwight@verizon.com; Michael Hammer (mhammer); 'Brian Rosen'; > > > 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; > > > speermint@ietf.org > > > Subject: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - > OF > > > - SF > > > > > > Richard, > > > > > > Yes I know I was mixing data and mechanism-to-access-data. > > > Still I believe the major point to be correct. In many parts of the > > > world there are already mechanisms (associated with Local Number > > > Portability) to determine ownership of an E.164 number, hence use of > > > ENUM for this purpose alone, will be unnecessary. > > > > > > To be clear, I believe that providing access via Infrastructure ENUM > > > to LNP information may be very helpful; but only if Infrastructure > > > ENUM provides more than just this. > > > If an Infrastructure ENUM query can combine (a) determination of > the > > > entity providing service to the destination, (b) determination of > the > > > corresponding LRN, if one exists, and (c) mapping of the routable > > > number (either the number originally indicated, or the LRN) to a > Layer > > > 5 "point of ingress" specified by the entity providing service to > the > > > destination; then Infrastructure ENUM is quite a handy mechanism. > If > > > all it does is (a) then I don't need it. > > > > > > But in the end this is neither here nor there. I am not wedded to > any > > > specific technology, I just need workable solutions to real business > > > problems. > > > > > > Tim > > > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, May 24, 2006 4:38 PM > > > To: timothy.dwight@verizon.com; timothy.dwight@verizon.com; Michael > > > Hammer (mhammer); Brian Rosen; Francois D. Menard; Khan, Sohel Q > > > [CTO]; David Meyer; speermint@ietf.org > > > Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture - LF - > OF > > > - SF > > > > > > Tim, > > > > > > thanx for your reply, you are raising some important issues. > > > Since it is already midnight here, I will reply to it in detail > > > tomorrow > > > > > > I am also working on a more detailed analysis and a draft which will > > > require even some more time. > > > > > > Just a quick one: > > > > > > >In some parts of the world the function provided by "option > > > 2" usage of > > > >Infrastructure ENUM could be achieved in other ways (e.g., > > > the LERG and > > > >NPDB in North America) so in those cases Infrastructure ENUM > > > might be a > > > >superfluous concept; but if that's the right technical > > > answer so be it. > > > > > > Yes and no ;-) > > > You are mixing up here the Registry and the ENUM DNS. > > > The Registry is the LERG and NPDB (or is derived from), the ENUM DNS > > > is the equivalent on IP of the SCP in the PSTN where the date is > > > downloaded to. > > > > > > Richard > > > > > > > > > ________________________________ > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > Gesendet: Mi 24.05.2006 23:00 > > > An: Stastny Richard; timothy.dwight@verizon.com; 'Michael Hammer > > > (mhammer)'; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q > > > [CTO]'; 'David Meyer'; speermint@ietf.org > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - > OF > > > - SF > > > > > > > > > > > > Richard, > > > > > > Thank you for the clarification. I understand the distinction you > are > > > making. > > > > > > My objective is to be able to translate a destination identifier > > > (E.164 number of alphanumeric AoR) into the address of a Layer 5 > > > entity designated by the organization providing service to the > called > > > party. With infrastructure/carrier ENUM I could do this (as > described > > > in your Option 1), but because ENUM is specific to E.164 numbers it > > > would only work for E.164 -formatted destination identifiers. > > > > > > In pictures, your Option 2 seems to me to imply the following: > > > > > > +----------------+ +----------+ > > > E.164 | infrastructure | serving | identify > > > | network > > > ingress > > > destination -->| ENUM |---> carrier --->| ingress > > > |---> point > > > specified > > > identifier | (option 2) | identity | point | > by > > > serving carrier > > > +----------------+ ^ +----------+ > > > | > > > +----------------+ | > > > non-E.164 | map domain in | | > > > Destination -->| URI to carrier |--------+ > > > Identifier | identity | > > > +----------------+ > > > > > > In some parts of the world the function provided by "option 2" usage > > > of Infrastructure ENUM could be achieved in other ways (e.g., the > LERG > > > and NPDB in North America) so in those cases Infrastructure ENUM > might > > > be a superfluous concept; but if that's the right technical answer > so > > > be it. > > > > > > The "identify ingress point" function would need to be defined. I > > > would like it to consider the specified destination (in addition to > > > the carrier providing service to that destination); and I would like > > > the procedures to be such that the serving carrier controls (in a > > > reasonably dynamic > > > way) the point at which traffic destined to a particular > destination, > > > enters his network. If those requirements can be met, I think this > > > approach is workable. > > > > > > Its biggest drawback is that it precludes a solution ("option 1" > usage > > > of Infrastructure ENUM) that is sufficient for the majority of > today's > > > needs. > > > It optimizes for a problem that will exist in the future at the > > > expense of solving problems that exist today. I realize that > solving > > > today's problems may not be SPEERMINT's focus, or (arguably) even > > > within its charter, but I would hate to see recommendations from > > > SPEERMINT preclude or significantly delay solving them. > > > > > > Suppose we did something like this: > > > > > > +----------+ [pseudo +----------------+ > > > non-E.164 | identify | or real] | infrastructure > > > | network > > > ingress > > > destination -->| "pseudo" |---> E.164 --->| ENUM > > > |---> point > > > specified > > > identifier | E.164 | number | (option 1) | > by > > > serving carrier > > > +----------+ +----------------+ > > > > > > We could let the ENUM working group define Infrastructure ENUM as > > > described in your Option 1 (which is as you know already > commercially > > > available from a few sources) and SPEERMINT could define the > "identify > > > pseudo E.164" function that in my diagram feeds into it. This > > > function might be as simple as mapping the domain part of the URI to > > > an E.164 number uniquely associated with the network providing > service > > > to the specified destination. Unless this is a lot harder than it > > > seems, this shouldn't keep us busy too long :-) > > > > > > > > > Tim > > > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, May 24, 2006 11:16 AM > > > To: timothy.dwight@verizon.com; Michael Hammer (mhammer); > > > Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David > > > Meyer; speermint@ietf.org > > > Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture - > > > LF - OF - SF > > > > > > Tim, > > > > > > >> ... the basic idea of Infrastructure ENUM (which will be used for > > > >> service providers is to provide a domain name in a SIP URI =3D = a > > > >> service provider ID > > > >(SPID) > > > > > > >At the risk of asking an off-topic question (realizing that > > > ENUM is not > > > >within scope for SPEERMINT), can I ask where the idea that > > > >Infrastructure ENUM queries return SPIDs, comes from? It is > > > my intent > > > >to provide a point of interconnection to be used by the requesting > > > >entity to hand to me a call to the specified number. I do > > > not intend > > > >that the only meaningful part of the URI returned from the > > > ENUM query, > > > >be > > > the domain name. > > > > > > thank you for raising this important point. I tried to raise > > > this some time ago, but got no clear answer > > > > > > Currently there exist two lines of thought about the usage of > > > Infrastructure (and also Carrier ENUM in private trees) > > > > > > 1. Put in ENUM the ingress point(s) e.g. > > > sip:+43xxxx@sbc4711.provider.net 2. > > > Put in ENUM the AoR only: e.g. sip:+43xxx@provider.net > > > (provider.net is what I meant with SPID) > > > > > > Most currently prefer option 1, especially in private ENUM trees. > > > > > > IMHO this is the wrong approach: > > > > > > There should be a clear separation (and it is in the charter) > > > between ENUM and SPEERMINT SPEERMINT peering MUST be able to > > > work standalone and without ENUM. > > > > > > Option 1 assumes also that the user is entering ALWAYS an > > > E.164 number as identifier. > > > > > > But what if he is entering an AoR? > > > > > > SPEEMINT peering MUST be able to resolve this too so you need > > > to find the ingress point independant of ENUM e.g. via RFC3263. > > > > > > If this MUST be possible, why not enter in (any) ENUM just > > > the AoR, if you must be able to resolve the AoR anyway? > > > > > > Otherwise you need to manage two mappings separate 1. the > > > E.164 to ingress point 2. the AoR mapping to ingress point > > > > > > this is not a good idea > > > > > > This is the reason why I would prefer to enter in ENUM AoRs > > > only the user part in ENUM is always the E.164 number (for > > > privacy reasons) the domain part is the SPID, which is mapped > > > later to find the ingress point > > > > > > the calling user may then also use an alis AoR such as > > > sip:name@provider.net > > > > > > regards > > > > > > Richard > > > > > > > > > > > > ________________________________ > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > Gesendet: Mi 24.05.2006 16:46 > > > An: Stastny Richard; 'Michael Hammer (mhammer)'; 'Brian > > > Rosen'; 'Francois D. > > > Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; speermint@ietf.org > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - > > > LF - OF - SF > > > > > > > > > > > > Stastny, Richard said: > > > > > > > ... the basic idea of Infrastructure ENUM (which will be used for > > > > service providers is to provide a domain name in a SIP URI > > > =3D a service > > > > provider ID > > > (SPID) > > > > > > At the risk of asking an off-topic question (realizing that > > > ENUM is not within scope for SPEERMINT), can I ask where the > > > idea that Infrastructure ENUM queries return SPIDs, comes > > > from? It is my intent to provide a point of interconnection > > > to be used by the requesting entity to hand to me a call to > > > the specified number. I do not intend that the only > > > meaningful part of the URI returned from the ENUM query, be > > > the domain name. > > > > > > tim > > > > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 11:24:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjeAa-0003h0-OS; Fri, 26 May 2006 11:24:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjeAR-0003bu-Jt for speermint@ietf.org; Fri, 26 May 2006 11:23:59 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjdyW-0005cf-HD for speermint@ietf.org; Fri, 26 May 2006 11:11:42 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 652D11A337; Fri, 26 May 2006 17:11:39 +0200 (CEST) Date: Fri, 26 May 2006 17:11:39 +0200 From: Otmar Lendl To: "Michael Hammer (mhammer)" Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Message-ID: <20060526151139.GC27495@nic.at> Mail-Followup-To: Otmar Lendl , "Michael Hammer (mhammer)" , "Khan, Sohel Q [CTO]" , speermint@ietf.org References: <072C5B76F7CEAB488172C6F64B30B5E301847D95@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301847D95@xmb-rtp-20b.amer.cisco.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: "Khan, Sohel Q \[CTO\]" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Michael, On 2006/05/25 18:05, "Michael Hammer (mhammer)" wrote: > > If an address is advertized in public ENUM or DNS, then it ought not be > unreachable due to use of private networks or NATs, which is the basis > for some of your arguments about why not SIP. We're moving a bit into ENUM WG turf here, but anyway. We're in a bit of a dilemma here regarding infrastructure ENUM: On a national level it's manageable to build a private DNS which only proper (whatever than means) operators can access. Thus you can build a system that has the feature "if you can see the URI, then you can reach it". On an international level I consider this to be impossible. The definitions about who is a proper carrier or not will vary a great deal and I doubt that a big incumbent in one country will want to directly talk to an upstart VoIP operator two continents away. Keeping that tree hidden from public view is quite impossible if you consider the scope of the legitimate readers. Consistent selective visibility in a distributed DNS tree is very tricky. [e164.info managed to do so on a small scale, but they use a central DB. I doubt that you can scale up their system to worldwide, non-centralized one.] My conclusion from that is that * infrastructure ENUM will be public (if it wants to enable more than just national peerings). * Thus the reachability assumption will have to yield. I wish it weren't so. But I haven't found a way to avoid this conclusion. Do you see other options? > My thinking was that one would need to progress through a series of > steps/functions where the bootstrap steps are very public, but the later > steps depend on the previous step enabling it. The chicken or egg > problem shouldn't occur for first steps. That's why we put the bootstrapping steps into the DNS. Any other system SPEERMINT will come up with, e.g. some SUBSCRIBE/NOTIFY would fit in very nicely: the domain policy the can reference this framework as the requirement to reach the destination. > (I do understand your model > where you advertise what is only reachable by a few, but then it is > working as you intended with selective unreachability being part of your > design.) As I see the market right now, we already have a very selective reachability on the SIP layer between VoIP operators. I can't see a way to move the state of affairs to "interconnection on SIP basis between all commercial VoIP-operators worldwide" without either * building a SIP routing protocol complete with transit networks (the BGP model) or * require the possibility of direct connections between all operators worldwide. Determining whether the caller from halfway around the globe is a legitimate operator is massively difficult, thus we end running open servers. (the email model) Thus I think selective reachability on SIP will stay with us for the medium term. > Hopefully, any delays to call setup occur only because of initial > contact to previously unknown domains. For, previously contacted > domains or for federations that use a central SIP proxy or some > interconnect SIP fabric, the call can be quickly handed to the heavily > used local contact point for that federation, since they were learned > previous to the call. That sounds good. > Anyway, it may be possible through configuration to address both ways, > with some heuristic to guide when to transition from the "policy is > simple" approach to the "policy is complex" approach. Even if the policy record just states "this is a carrier URI, calls must use RFC-SPEERMINT-SUBSCRIPTIONS", this is helpful for callers. I see domain policies as the meta-protocol to bootstrap various other peering mechanisms. The adoption of my draft thus does not preclude further work in speermint. Quite the contrary. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 11:24:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjeAk-0003mX-3o; Fri, 26 May 2006 11:24:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjeAb-0003hw-Ma for speermint@ietf.org; Fri, 26 May 2006 11:24:09 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjeAZ-0006AO-BP for speermint@ietf.org; Fri, 26 May 2006 11:24:09 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 26 May 2006 11:24:08 -0400 X-IronPort-AV: i="4.05,177,1146456000"; d="scan'208"; a="89559396:sNHT34487984" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4QFO6TL013030; Fri, 26 May 2006 11:24:06 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 May 2006 11:24:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Fri, 26 May 2006 11:24:05 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3018480EA@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaAMoodlv4ELGDzSDmUN9oHx1KZCQApLR4Q From: "Michael Hammer \(mhammer\)" To: "Otmar Lendl" X-OriginalArrivalTime: 26 May 2006 15:24:06.0723 (UTC) FILETIME=[6DA18130:01C680D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: "Khan, Sohel Q \[CTO\]" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Otmar, I like the way you laid this out. =20 My intent was to have something more like the O(n) scaling you describe in your first option, only you don't get the information needed to peer from the DNS, but from the Policy Server handling Subscriptions. =20 I don't know what it means to "almost require". Just as with your DNS-oriented case, if you set up policies and Subscription responses to be conditioned on the federation that a querier claims to be part of, backed up by valid certificates signed by that federation, then you can respond positively without previous manual configurations for that specific peer. The peer only needs proof that it is part of the federation. Bottom line: It doesn't matter which server type provides the data. Mike > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at]=20 > Sent: Thursday, May 25, 2006 3:36 PM > To: Michael Hammer (mhammer) > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 >=20 > Michael, >=20 > On 2006/05/24 16:05, "Michael Hammer (mhammer)"=20 > wrote: > >=20 > > I think our main difference is that I am suspecting that the policy=20 > > will be large and possibly very dynamic, thus less suitable for=20 > > locating in DNS. Also, instead of pointing directly to a single=20 > > policy document, which seems like a one-size-fits-all periodic user=20 > > poll option,; rather, use Subscriptions where the resulting=20 > document=20 > > may depend on authentication and who is asking, and can be=20 > pushed on=20 > > the schedule of the server when the policy changes. > >=20 > > These are just suggestions being thrown out for discussion.=20 > I'd like=20 > > to hear what folks think about them. >=20 > Re-reading your mail I found one aspect I'd like to highlight: >=20 > If you talk about a "subscription" of some sort, I assume=20 > that you mean that the originating network kind of registeres=20 > at the destination network and receives updates about the=20 > state of this peering relationship. In a way, this sound=20 > similar to what BGP does. >=20 > Have I interpreted this correctly? If not, please ignore the=20 > rest of this mail. >=20 > The reason we decided NOT go this route is the following: >=20 > Once you require that the border element of a SIP operator=20 > establishes a permanent session with the ingress elements of=20 > its peer before any calls can traverse this peering, then you=20 > almost require the manual configuration of this peering. >=20 > That's fine if you take the peering model of BGP as reference. > Layer 3 peering requires a physical connection (except at=20 > exchange points), peering is thus always an explicit and=20 > human decision and thus the manual BGP configuration is no issue. >=20 > Peering at the SIP layer is different: you usually don't need=20 > build any extra physical connection. You can instantly peer=20 > with all other SIP services connected to the Internet once=20 > you're connected to it. The range of peering partners thus=20 > isn't limited to the ones to which you build a direct=20 > physical link. The set of potential peering partners is huge=20 > and reaching them does not involve any additional lower layer work. >=20 > In the spirit of the Internet end-to-end model, I consider it=20 > thus essential to design a system with which all these VoIP=20 > operators can in effect establish peering relationships with=20 > each other. > I won't force ubiquitous peering on all VSPs, but the system=20 > should make it possible. >=20 > As an example, consider the following scenario: >=20 > A set of VoIP service providers form an association and=20 > exchange traffic > via the public Internet using SIP with the TCP/TLS=20 > transport protocol > for confidentiality and peer authenticity by using X.509=20 > certificates > signed by the association's certificate authority. >=20 > If a new operator joins such a club, what needs to happen? >=20 > With domain policies the following: >=20 > * the new guy get's his TLS cert signed > * the new guy configures his ingress points to allow connections > via TLS and a correct cert > * he announces his membership in that federation by adding a NAPTR > record to his domain >=20 > That gives us O(n) scaling. >=20 > Imagine what needs to happen if you have to configure BGP-like links: >=20 > * the new guy has to estabish links to all existing members > * and the reverse: all existing members have to be told about this > new guy and have to configure their side of the peering link. >=20 > This has complexity of O(n*n). >=20 > (or do you have something similar like the BGP=20 > route-reflectors in mind?) >=20 > --------------- >=20 > If some group of operators want pre-configured links (and=20 > thus O(n*n) complexity), fine, let them do that within their=20 > federation.=20 > My proposal doesn't rule that out.=20 >=20 > On the other hand I think we should be extremely careful not=20 > to build something with precludes setups with far better=20 > scaling properties. >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 11:25:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjeBY-0004GC-1o; Fri, 26 May 2006 11:25:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjeAP-0003a2-Rz for speermint@ietf.org; Fri, 26 May 2006 11:23:57 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fje2O-0005i7-Io for speermint@ietf.org; Fri, 26 May 2006 11:15:42 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k4QFAVu26703; Fri, 26 May 2006 11:10:31 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Location Function in SPEERMINT Date: Fri, 26 May 2006 11:15:33 -0400 Message-ID: In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3018480AF@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Location Function in SPEERMINT Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAATumxgAG4BNwABEZoVAADQ2DIAAC1z/9AAGrFeAACZ2pfQABju7wACHfcEAAAbB9IAAK1HH6AAC9BtAAAGOAdAAAMvVgACTEanAAAMf18AAA1j4A From: "James McEachern" To: "Michael Hammer \(mhammer\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b67ab81b2db0d00304056d0360a5a39a Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org So are you saying that it should be a requirement? -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Friday, May 26, 2006 10:52 AM To: McEachern, James [CAR:5N00:EXCH]; Reinaldo Penno; Stastny Richard; = timothy.dwight@verizon.com; timothy.dwight@verizon.com; Brian Rosen; = Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org Subject: RE: [Speermint] Location Function in SPEERMINT Distance is dead IF the proxy does not have strong ties to a media anchor point. If there is such a media anchor point, then choosing ones that are close to calling and called parties will aid in finding shortest routes between parties. However, I am not advocating for or against such media anchors, just simply recognizing that they may exist depending on a domain's architecture. There may be other reasons that peers are directed to one proxy over another. It is useful for the domain to designate which proxies peers should use. Mike > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com]=20 > Sent: Friday, May 26, 2006 10:44 AM > To: Reinaldo Penno; Stastny Richard;=20 > timothy.dwight@verizon.com; Michael Hammer (mhammer);=20 > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard;=20 > Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > Subject: RE: [Speermint] Location Function in SPEERMINT >=20 > >This tells you the SIP proxy to be contacted. It does not=20 > tell you if=20 > >this the closest Sip Proxy handling @example.com users. It also does=20 > >not tell you if it is the closest proxy to the callee. >=20 > Is the ability to "identify the closest proxy" a requirement=20 > for Speermint? Many people have pointed out that distance is=20 > dead, or at least should be, so it isn't clear to me that we=20 > really care. The Requirements and Terminology draft doesn't=20 > explicitly say, but my reading of section 5.2 implies this is=20 > not a requirement.=20 >=20 > That having been said, I don't necessarily have strong views=20 > either way. I'd just like to be clear on whether or not it=20 > is a requirement. >=20 > Jim >=20 >=20 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Thursday, May 25, 2006 5:00 PM > To: Stastny Richard; timothy.dwight@verizon.com; Michael=20 > Hammer (mhammer); timothy.dwight@verizon.com; Brian Rosen;=20 > Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer;=20 > speermint@ietf.org > Subject: RE: [Speermint] Location Function in SPEERMINT >=20 > I believe it is enough. You could refine it but I might sure=20 > of the benefits. Maybe this problem was already solved=20 > somewhere and I'm not aware.=20 >=20 > For example, The UAs would care. >=20 > >From RFC3263 >=20 > ;; Priority Weight Port Target > IN SRV 0 1 5060 server1.example.com > IN SRV 0 2 5060 server2.example.com >=20 > This tells you the SIP proxy to be contacted. It does not=20 > tell you if this the closest Sip Proxy handling @example.com=20 > users. It also does not tell you if it is the closest proxy=20 > to the callee. >=20 > In the case of a carriers providing VoIP service to a user,=20 > if this provider A peers with provider B in two different=20 > locations, which one to choose to send to forward the call? >=20 > Regards, >=20 > Reinaldo >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, May 25, 2006 1:52 PM > > To: Reinaldo Penno; timothy.dwight@verizon.com; Michael Hammer > (mhammer); > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > Sohel Q > > [CTO]; David Meyer; speermint@ietf.org > > Subject: Re: [Speermint] Location Function in SPEERMINT > >=20 > > Reinaldo said: > > >That's maybe one of the most important issues. This could be > complicated > > >by the geographically dispersed networks with several entry points. > > >Although this might be an interesting problem it might be=20 > a rathole. > >=20 > > So you say RFC 3263 is not enough, something is missing? > > e.g. the geographic location of originating and terminating=20 > --- what? > >=20 > > -SIP proxy? who cares > > -SBC? > > -UA? > >=20 > > So we are again dealing with SBCs, in this case the geo-location of > these > > -- rats, holes ;-) > >=20 > > Richard > >=20 > >=20 > > ________________________________ > >=20 > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > Gesendet: Do 25.05.2006 22:37 > > An: Stastny Richard; timothy.dwight@verizon.com; Michael Hammer > (mhammer); > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > Sohel Q > > [CTO]; David Meyer; speermint@ietf.org > > Betreff: RE: [Speermint] Location Function in SPEERMINT > >=20 > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, May 25, 2006 1:26 PM > > > To: timothy.dwight@verizon.com; Michael Hammer (mhammer);=20 > > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > > Sohel Q > > > [CTO]; David Meyer; speermint@ietf.org > > > Subject: [Speermint] Location Function in SPEERMINT > > > > > > Hi all, > > > > > > sorry, but I am only able to reply with a short=20 > statement, because I > > am > > > on vacation and have only limited time and bandwitdh (GPRS) > > > > > > First, I consider this discussion regarding Infrastructure ENUM, > LERG > > and > > > LNP > > > important, but in the wrong WG. It should be discussed in ENUM. WG > and > > > not in SPEERMINT > > > > > > SPEERMINT is only dealing with Call Routing Data (CRD), which is > > defined > > > as the OUTPUT of ENUM or some other means. > > > > > > This implies, that the location function (LF) defined in the=20 > > > achitecture draft happens AFTER an ENUM query and=20 > therefore cannot=20 > > > be the part of the LF. > > > > > > The LF can only involve the location of the destination "network" > > > as defined in SPEERMINT by the use of CRD (which is=20 > basically a SIP=20 > > > URI because we are currently talking only SIP in SPEERMINT) > > > > > > Of course SPEERMINT needs to define what it considers=20 > CRD, and AoR=20 > > > or the ingress point of a network. > > > > > > BUT then SPEERMINT needs also to define how the ingress=20 > point of a=20 > > > "network" is LOCATED given a SIP AoR. > > [[Reinaldo]] > >=20 > > That's maybe one of the most important issues. This could be > complicated > > by the geographically dispersed networks with several entry points. > > Although this might be an interesting problem it might be a rathole. > >=20 > >=20 > > > > > > Richard > > > > > > > > > ________________________________ > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > Gesendet: Do 25.05.2006 20:17 > > > An: 'Michael Hammer (mhammer)';=20 > timothy.dwight@verizon.com; Stastny=20 > > > Richard; 'Brian Rosen'; 'Francois D. Menard'; 'Khan,=20 > Sohel Q [CTO]';=20 > > > 'David Meyer'; speermint@ietf.org > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - > OF > > - SF > > > > > > > > > > > > Michael Hammer said: > > > > > > > Tim, > > > > > > > > The LERG and LNP databases are intrinsically tied to=20 > the operation > > of > > > the > > > TDM > > > > infrastructure. Any design that perpatuates these systems when > > their > > > reason > > > > for being (TDM) goes away is a faulty design. > > > > > > OK with me. I only meant to point out that right now I=20 > have these=20 > > > capabilities, so recreating them isn't a high priority. > > > > > > > > > > > > > > DNS and ENUM provides the equivalent information and=20 > mechanisms to > > do > > > what > > > is > > > > needed in the IP domain. As such, a design that makes > dependencies > > on > > > legacy > > > > systems is deficient. I wouldn't support such a kludge. > > > > > > Fine. > > > > > > I'm a big fan of IP-domain solutions. Specifically Infrastructure > > ENUM > > > looks really handy; my point before was that it's moreso when used > in > > what > > > Richard called "option 1". The alternative ("option 2") only > > replicates > > > the > > > "kludge" to which I already have access. > > > > > > And to be fair to Richard, he did point out (subtly) that=20 > the latter > > claim > > > is a bit myopic. There are existing means by which VSPs can gain > > access > > > to > > > number portability information relative to national destinations. > > They > > > don't have such access, at least not easily and not=20 > universally, to > > number > > > portability information relative to international=20 > destinations. If > > that > > > could be provided by Infrastructure ENUM (either "option 1" or > "option > > 2") > > > it would be useful and would not simply replicate existing > > capabilities. > > > > > > Bottom line, both options defined by Richard, would add value. > Option > > 1 > > > adds more value but is specific to destinations=20 > identified by E.164=20 > > > numbers or URIs with imbedded E.164 numbers. Which is=20 > the problem=20 > > > closest > to > > > hand. > > > > > > > > > > > > > > That said, if there are backward compatibilities during the > > transition, > > > where > > > > some information just happens to be known by external systems, > such > > as > > > you > > > suggest > > > > below, I don't see that as a problem. I am just wary=20 > of ending up > > with > > > two > > > > systems in the end when one would do. > > > > > > Isn't it inevitable that for some time, both will exist? Just as > the > > GSTN > > > and VoIP will coexist for some time, so will their supporting=20 > > > infrastructure. > > > > > > Don't get me wrong. I'm not saying "because I have an SS7 -based > > solution > > > to LNP I don't need an IP -based solution". All I'm=20 > saying is that > > when > > > given the option of using Infrastructure ENUM to recreate (and in > the > > case > > > of international destinations, extend) the capability I already > have, > > and > > > using it to do that and more, I'm inclined to prefer the latter. > > > > > > > > > > > > > > Mike > > > > > > > > > > -----Original Message----- > > > > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > Sent: Wednesday, May 24, 2006 6:19 PM > > > > To: 'Stastny Richard'; timothy.dwight@verizon.com;=20 > > > > timothy.dwight@verizon.com; Michael Hammer (mhammer); 'Brian > Rosen'; > > > > 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer';=20 > > > > speermint@ietf.org > > > > Subject: RE: [Speermint] RE: SPEERMINT Peering=20 > Architecture - LF - > > OF > > > > - SF > > > > > > > > Richard, > > > > > > > > Yes I know I was mixing data and mechanism-to-access-data. > > > > Still I believe the major point to be correct. In many parts of > the > > > > world there are already mechanisms (associated with Local Number > > > > Portability) to determine ownership of an E.164 number,=20 > hence use > of > > > > ENUM for this purpose alone, will be unnecessary. > > > > > > > > To be clear, I believe that providing access via Infrastructure > ENUM > > > > to LNP information may be very helpful; but only if=20 > Infrastructure=20 > > > > ENUM provides more than just this. > > > > If an Infrastructure ENUM query can combine (a)=20 > determination of > > the > > > > entity providing service to the destination, (b)=20 > determination of > > the > > > > corresponding LRN, if one exists, and (c) mapping of=20 > the routable=20 > > > > number (either the number originally indicated, or the LRN) to a > > Layer > > > > 5 "point of ingress" specified by the entity providing=20 > service to > > the > > > > destination; then Infrastructure ENUM is quite a handy=20 > mechanism. > > If > > > > all it does is (a) then I don't need it. > > > > > > > > But in the end this is neither here nor there. I am=20 > not wedded to > > any > > > > specific technology, I just need workable solutions to real > business > > > > problems. > > > > > > > > Tim > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Wednesday, May 24, 2006 4:38 PM > > > > To: timothy.dwight@verizon.com; timothy.dwight@verizon.com; > Michael > > > > Hammer (mhammer); Brian Rosen; Francois D. Menard;=20 > Khan, Sohel Q=20 > > > > [CTO]; David Meyer; speermint@ietf.org > > > > Subject: Re: [Speermint] RE: SPEERMINT Peering=20 > Architecture - LF - > > OF > > > > - SF > > > > > > > > Tim, > > > > > > > > thanx for your reply, you are raising some important issues. > > > > Since it is already midnight here, I will reply to it in detail=20 > > > > tomorrow > > > > > > > > I am also working on a more detailed analysis and a draft which > will > > > > require even some more time. > > > > > > > > Just a quick one: > > > > > > > > >In some parts of the world the function provided by "option > > > > 2" usage of > > > > >Infrastructure ENUM could be achieved in other ways (e.g., > > > > the LERG and > > > > >NPDB in North America) so in those cases Infrastructure ENUM > > > > might be a > > > > >superfluous concept; but if that's the right technical > > > > answer so be it. > > > > > > > > Yes and no ;-) > > > > You are mixing up here the Registry and the ENUM DNS. > > > > The Registry is the LERG and NPDB (or is derived from), the ENUM > DNS > > > > is the equivalent on IP of the SCP in the PSTN where=20 > the date is=20 > > > > downloaded to. > > > > > > > > Richard > > > > > > > > > > > > ________________________________ > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > Gesendet: Mi 24.05.2006 23:00 > > > > An: Stastny Richard; timothy.dwight@verizon.com;=20 > 'Michael Hammer=20 > > > > (mhammer)'; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q=20 > > > > [CTO]'; 'David Meyer'; speermint@ietf.org > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering=20 > Architecture - LF - > > OF > > > > - SF > > > > > > > > > > > > > > > > Richard, > > > > > > > > Thank you for the clarification. I understand the=20 > distinction you > > are > > > > making. > > > > > > > > My objective is to be able to translate a destination identifier > > > > (E.164 number of alphanumeric AoR) into the address of=20 > a Layer 5=20 > > > > entity designated by the organization providing service to the > > called > > > > party. With infrastructure/carrier ENUM I could do this (as > > described > > > > in your Option 1), but because ENUM is specific to E.164 numbers > it > > > > would only work for E.164 -formatted destination identifiers. > > > > > > > > In pictures, your Option 2 seems to me to imply the following: > > > > > > > > +----------------+ +----------+ > > > > E.164 | infrastructure | serving | identify > > > > | network > > > > ingress > > > > destination -->| ENUM |---> carrier --->| ingress > > > > |---> point > > > > specified > > > > identifier | (option 2) | identity | point | > > by > > > > serving carrier > > > > +----------------+ ^ +----------+ > > > > | > > > > +----------------+ | > > > > non-E.164 | map domain in | | > > > > Destination -->| URI to carrier |--------+ > > > > Identifier | identity | > > > > +----------------+ > > > > > > > > In some parts of the world the function provided by "option 2" > usage > > > > of Infrastructure ENUM could be achieved in other ways=20 > (e.g., the > > LERG > > > > and NPDB in North America) so in those cases Infrastructure ENUM > > might > > > > be a superfluous concept; but if that's the right=20 > technical answer > > so > > > > be it. > > > > > > > > The "identify ingress point" function would need to be=20 > defined. I=20 > > > > would like it to consider the specified destination (in addition > to > > > > the carrier providing service to that destination); and I would > like > > > > the procedures to be such that the serving carrier=20 > controls (in a=20 > > > > reasonably dynamic > > > > way) the point at which traffic destined to a particular > > destination, > > > > enters his network. If those requirements can be met, I think > this > > > > approach is workable. > > > > > > > > Its biggest drawback is that it precludes a solution ("option 1" > > usage > > > > of Infrastructure ENUM) that is sufficient for the majority of > > today's > > > > needs. > > > > It optimizes for a problem that will exist in the future at the=20 > > > > expense of solving problems that exist today. I realize that > > solving > > > > today's problems may not be SPEERMINT's focus, or=20 > (arguably) even=20 > > > > within its charter, but I would hate to see=20 > recommendations from=20 > > > > SPEERMINT preclude or significantly delay solving them. > > > > > > > > Suppose we did something like this: > > > > > > > > +----------+ [pseudo +----------------+ > > > > non-E.164 | identify | or real] | infrastructure > > > > | network > > > > ingress > > > > destination -->| "pseudo" |---> E.164 --->| ENUM > > > > |---> point > > > > specified > > > > identifier | E.164 | number | (option 1) | > > by > > > > serving carrier > > > > +----------+ +----------------+ > > > > > > > > We could let the ENUM working group define=20 > Infrastructure ENUM as=20 > > > > described in your Option 1 (which is as you know already > > commercially > > > > available from a few sources) and SPEERMINT could define the > > "identify > > > > pseudo E.164" function that in my diagram feeds into it. This=20 > > > > function might be as simple as mapping the domain part=20 > of the URI > to > > > > an E.164 number uniquely associated with the network providing > > service > > > > to the specified destination. Unless this is a lot=20 > harder than it=20 > > > > seems, this shouldn't keep us busy too long :-) > > > > > > > > > > > > Tim > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Wednesday, May 24, 2006 11:16 AM > > > > To: timothy.dwight@verizon.com; Michael Hammer (mhammer); Brian=20 > > > > Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer;=20 > > > > speermint@ietf.org > > > > Subject: Re: [Speermint] RE: SPEERMINT Peering=20 > Architecture - LF -=20 > > > > OF - SF > > > > > > > > Tim, > > > > > > > > >> ... the basic idea of Infrastructure ENUM (which will be used > for > > > > >> service providers is to provide a domain name in a=20 > SIP URI =3D a=20 > > > > >> service provider ID > > > > >(SPID) > > > > > > > > >At the risk of asking an off-topic question (realizing that > > > > ENUM is not > > > > >within scope for SPEERMINT), can I ask where the idea that=20 > > > > >Infrastructure ENUM queries return SPIDs, comes from? It is > > > > my intent > > > > >to provide a point of interconnection to be used by the > requesting > > > > >entity to hand to me a call to the specified number. I do > > > > not intend > > > > >that the only meaningful part of the URI returned from the > > > > ENUM query, > > > > >be > > > > the domain name. > > > > > > > > thank you for raising this important point. I tried to=20 > raise this=20 > > > > some time ago, but got no clear answer > > > > > > > > Currently there exist two lines of thought about the usage of=20 > > > > Infrastructure (and also Carrier ENUM in private trees) > > > > > > > > 1. Put in ENUM the ingress point(s) e.g. > > > > sip:+43xxxx@sbc4711.provider.net 2. > > > > Put in ENUM the AoR only: e.g. sip:+43xxx@provider.net=20 > > > > (provider.net is what I meant with SPID) > > > > > > > > Most currently prefer option 1, especially in private=20 > ENUM trees. > > > > > > > > IMHO this is the wrong approach: > > > > > > > > There should be a clear separation (and it is in the charter)=20 > > > > between ENUM and SPEERMINT SPEERMINT peering MUST be=20 > able to work=20 > > > > standalone and without ENUM. > > > > > > > > Option 1 assumes also that the user is entering ALWAYS an > > > > E.164 number as identifier. > > > > > > > > But what if he is entering an AoR? > > > > > > > > SPEEMINT peering MUST be able to resolve this too so=20 > you need to=20 > > > > find the ingress point independant of ENUM e.g. via RFC3263. > > > > > > > > If this MUST be possible, why not enter in (any) ENUM just the=20 > > > > AoR, if you must be able to resolve the AoR anyway? > > > > > > > > Otherwise you need to manage two mappings separate 1. the > > > > E.164 to ingress point 2. the AoR mapping to ingress point > > > > > > > > this is not a good idea > > > > > > > > This is the reason why I would prefer to enter in ENUM=20 > AoRs only=20 > > > > the user part in ENUM is always the E.164 number (for privacy=20 > > > > reasons) the domain part is the SPID, which is mapped later to=20 > > > > find the ingress point > > > > > > > > the calling user may then also use an alis AoR such as=20 > > > > sip:name@provider.net > > > > > > > > regards > > > > > > > > Richard > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > Gesendet: Mi 24.05.2006 16:46 > > > > An: Stastny Richard; 'Michael Hammer (mhammer)'; 'Brian Rosen';=20 > > > > 'Francois D. > > > > Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer';=20 > speermint@ietf.org > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering=20 > Architecture - LF -=20 > > > > OF - SF > > > > > > > > > > > > > > > > Stastny, Richard said: > > > > > > > > > ... the basic idea of Infrastructure ENUM (which will be used > for > > > > > service providers is to provide a domain name in a SIP URI > > > > =3D a service > > > > > provider ID > > > > (SPID) > > > > > > > > At the risk of asking an off-topic question (realizing=20 > that ENUM=20 > > > > is not within scope for SPEERMINT), can I ask where the=20 > idea that=20 > > > > Infrastructure ENUM queries return SPIDs, comes from? It is my=20 > > > > intent to provide a point of interconnection to be used by the=20 > > > > requesting entity to hand to me a call to the specified=20 > number. I=20 > > > > do not intend that the only meaningful part of the URI returned=20 > > > > from the ENUM query, be the domain name. > > > > > > > > tim > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 11:28:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjeET-0006V1-FL; Fri, 26 May 2006 11:28:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjeES-0006Q6-Cv for speermint@ietf.org; Fri, 26 May 2006 11:28:08 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjeEM-0006ab-TX for speermint@ietf.org; Fri, 26 May 2006 11:28:08 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 26 May 2006 11:28:02 -0400 X-IronPort-AV: i="4.05,177,1146456000"; d="scan'208"; a="89559870:sNHT34905926" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4QFS1vF018770; Fri, 26 May 2006 11:28:02 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 May 2006 11:28:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Fri, 26 May 2006 11:28:00 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3018480F1@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaAqao+Wsu/24IkSlOzT06Ie4ckkQALv1Gg From: "Michael Hammer \(mhammer\)" To: "Duane" , "Stastny Richard" X-OriginalArrivalTime: 26 May 2006 15:28:01.0550 (UTC) FILETIME=[F99942E0:01C680D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: "Khan, Sohel Q \[CTO\]" , speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Duane, Your argument depends on the assertion that it is only 20 more bytes of data. I don't think we are at a point yet to be able to conclude that conclusively. There may be a range of data from very simply to more complex. We need to work through this. Mike =20 > -----Original Message----- > From: Duane [mailto:duane@e164.org]=20 > Sent: Friday, May 26, 2006 5:49 AM > To: Stastny Richard > Cc: henry@pulver.com; Michael Hammer (mhammer); Otmar Lendl;=20 > Khan, Sohel Q [CTO]; speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > Stastny Richard wrote: >=20 > > Could you please elaborate a bit more in detail what=20 > exeactly you mean=20 > > with "overloading the DNS"? >=20 > That's usually a term thrown in by "purists" when they run=20 > out of other arguments, we store a lot of information in=20 > e164.org other then just SIP and we're no where near=20 > overloaded, actually we're heavily under utilised, although I=20 > tend to draw the line at storing redundant information (that=20 > could be found out from a SIP connection for example) unless=20 > there is a good reason otherwise. >=20 > > The root servers? the query types? the clients? specific=20 > servers? the Internet as a whole? >=20 > If the DNS system is this fragile that it can't cope with=20 > another 20 bytes of data (that is only accessed on demand) we=20 > should all call it a day and go home :) >=20 > --=20 >=20 > Best regards, > Duane >=20 > http://www.cacert.org - Free Security Certificates=20 > http://www.nodedb.com - Think globally, network locally=20 > http://www.sydneywireless.com - Telecommunications Freedom=20 > http://e164.org - Because e164.arpa is a tax on VoIP >=20 > "In the long run the pessimist may be proved right, > but the optimist has a better time on the trip." >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 11:38:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjeOb-0006Xx-TG; Fri, 26 May 2006 11:38:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjeOa-0006TR-VW for speermint@ietf.org; Fri, 26 May 2006 11:38:36 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FjeOX-0007z2-D3 for speermint@ietf.org; Fri, 26 May 2006 11:38:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: WG: [Speermint] Location Function in SPEERMINT Date: Fri, 26 May 2006 17:41:38 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A7A@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Location Function in SPEERMINT Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAATumxgAG4BNwABEZoVAADQ2DIAAC1z/9AAGrFeAACZ2pfQABju7wACHfcEAAAbB9IAAK1HH6AAC9BtAAAGOAdAAAMvVgACTEanAAAbMfjAAA+UBs From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: dd530fb5c702ad6eef32cae6dcb86145 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Too many recipients ;-) ________________________________ Von: Stastny Richard Gesendet: Fr 26.05.2006 17:13 An: James McEachern; Reinaldo Penno; timothy.dwight@verizon.com; Michael = Hammer (mhammer); timothy.dwight@verizon.com; Brian Rosen; Francois D. = Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org Betreff: Re: [Speermint] Location Function in SPEERMINT Before we say this is a requrement for SPEERMINT, we=20 need to define what "close" means on IP (especiallly on L5) And how to deal with "close" between UAs, I leave to the next generation = ;-) =20 Richard ________________________________ Von: James McEachern [mailto:jmce@nortel.com] Gesendet: Fr 26.05.2006 16:43 An: Reinaldo Penno; Stastny Richard; timothy.dwight@verizon.com; Michael = Hammer (mhammer); timothy.dwight@verizon.com; Brian Rosen; Francois D. = Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org Betreff: RE: [Speermint] Location Function in SPEERMINT >This tells you the SIP proxy to be contacted. It does not tell you if >this the closest Sip Proxy handling @example.com users. It also does = not >tell you if it is the closest proxy to the callee. Is the ability to "identify the closest proxy" a requirement for = Speermint? Many people have pointed out that distance is dead, or at = least should be, so it isn't clear to me that we really care. The = Requirements and Terminology draft doesn't explicitly say, but my = reading of section 5.2 implies this is not a requirement. That having been said, I don't necessarily have strong views either way. = I'd just like to be clear on whether or not it is a requirement. Jim -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Thursday, May 25, 2006 5:00 PM To: Stastny Richard; timothy.dwight@verizon.com; Michael Hammer = (mhammer); timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; = Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org Subject: RE: [Speermint] Location Function in SPEERMINT I believe it is enough. You could refine it but I might sure of the benefits. Maybe this problem was already solved somewhere and I'm not aware. For example, The UAs would care. >From RFC3263 ;; Priority Weight Port Target IN SRV 0 1 5060 server1.example.com IN SRV 0 2 5060 server2.example.com This tells you the SIP proxy to be contacted. It does not tell you if this the closest Sip Proxy handling @example.com users. It also does not tell you if it is the closest proxy to the callee. In the case of a carriers providing VoIP service to a user, if this provider A peers with provider B in two different locations, which one to choose to send to forward the call? Regards, Reinaldo > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, May 25, 2006 1:52 PM > To: Reinaldo Penno; timothy.dwight@verizon.com; Michael Hammer (mhammer); > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, Sohel Q > [CTO]; David Meyer; speermint@ietf.org > Subject: Re: [Speermint] Location Function in SPEERMINT > > Reinaldo said: > >That's maybe one of the most important issues. This could be complicated > >by the geographically dispersed networks with several entry points. > >Although this might be an interesting problem it might be a rathole. > > So you say RFC 3263 is not enough, something is missing? > e.g. the geographic location of originating and terminating --- what? > > -SIP proxy? who cares > -SBC? > -UA? > > So we are again dealing with SBCs, in this case the geo-location of these > -- rats, holes ;-) > > Richard > > > ________________________________ > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Do 25.05.2006 22:37 > An: Stastny Richard; timothy.dwight@verizon.com; Michael Hammer (mhammer); > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, Sohel Q > [CTO]; David Meyer; speermint@ietf.org > Betreff: RE: [Speermint] Location Function in SPEERMINT > > > > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, May 25, 2006 1:26 PM > > To: timothy.dwight@verizon.com; Michael Hammer (mhammer); > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > Sohel Q > > [CTO]; David Meyer; speermint@ietf.org > > Subject: [Speermint] Location Function in SPEERMINT > > > > Hi all, > > > > sorry, but I am only able to reply with a short statement, because I > am > > on vacation and have only limited time and bandwitdh (GPRS) > > > > First, I consider this discussion regarding Infrastructure ENUM, LERG > and > > LNP > > important, but in the wrong WG. It should be discussed in ENUM. WG and > > not in SPEERMINT > > > > SPEERMINT is only dealing with Call Routing Data (CRD), which is > defined > > as the OUTPUT of ENUM or some other means. > > > > This implies, that the location function (LF) defined in the > > achitecture draft happens AFTER an ENUM query and therefore > > cannot be the part of the LF. > > > > The LF can only involve the location of the destination "network" > > as defined in SPEERMINT by the use of CRD (which > > is basically a SIP URI because we are currently talking only SIP > > in SPEERMINT) > > > > Of course SPEERMINT needs to define what it considers CRD, > > and AoR or the ingress point of a network. > > > > BUT then SPEERMINT needs also to define how the ingress > > point of a "network" is LOCATED given a SIP AoR. > [[Reinaldo]] > > That's maybe one of the most important issues. This could be complicated > by the geographically dispersed networks with several entry points. > Although this might be an interesting problem it might be a rathole. > > > > > > Richard > > > > > > ________________________________ > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > Gesendet: Do 25.05.2006 20:17 > > An: 'Michael Hammer (mhammer)'; timothy.dwight@verizon.com; Stastny > > Richard; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; > > 'David Meyer'; speermint@ietf.org > > Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF > - SF > > > > > > > > Michael Hammer said: > > > > > Tim, > > > > > > The LERG and LNP databases are intrinsically tied to the operation > of > > the > > TDM > > > infrastructure. Any design that perpatuates these systems when > their > > reason > > > for being (TDM) goes away is a faulty design. > > > > OK with me. I only meant to point out that right now I have these > > capabilities, so recreating them isn't a high priority. > > > > > > > > > > DNS and ENUM provides the equivalent information and mechanisms to > do > > what > > is > > > needed in the IP domain. As such, a design that makes dependencies > on > > legacy > > > systems is deficient. I wouldn't support such a kludge. > > > > Fine. > > > > I'm a big fan of IP-domain solutions. Specifically Infrastructure > ENUM > > looks really handy; my point before was that it's moreso when used in > what > > Richard called "option 1". The alternative ("option 2") only > replicates > > the > > "kludge" to which I already have access. > > > > And to be fair to Richard, he did point out (subtly) that the latter > claim > > is a bit myopic. There are existing means by which VSPs can gain > access > > to > > number portability information relative to national destinations. > They > > don't have such access, at least not easily and not universally, to > number > > portability information relative to international destinations. If > that > > could be provided by Infrastructure ENUM (either "option 1" or "option > 2") > > it would be useful and would not simply replicate existing > capabilities. > > > > Bottom line, both options defined by Richard, would add value. Option > 1 > > adds more value but is specific to destinations identified by E.164 > > numbers > > or URIs with imbedded E.164 numbers. Which is the problem closest to > > hand. > > > > > > > > > > That said, if there are backward compatibilities during the > transition, > > where > > > some information just happens to be known by external systems, such > as > > you > > suggest > > > below, I don't see that as a problem. I am just wary of ending up > with > > two > > > systems in the end when one would do. > > > > Isn't it inevitable that for some time, both will exist? Just as the > GSTN > > and VoIP will coexist for some time, so will their supporting > > infrastructure. > > > > Don't get me wrong. I'm not saying "because I have an SS7 -based > solution > > to LNP I don't need an IP -based solution". All I'm saying is that > when > > given the option of using Infrastructure ENUM to recreate (and in the > case > > of international destinations, extend) the capability I already have, > and > > using it to do that and more, I'm inclined to prefer the latter. > > > > > > > > > > Mike > > > > > > > -----Original Message----- > > > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > Sent: Wednesday, May 24, 2006 6:19 PM > > > To: 'Stastny Richard'; timothy.dwight@verizon.com; > > > timothy.dwight@verizon.com; Michael Hammer (mhammer); 'Brian Rosen'; > > > 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; > > > speermint@ietf.org > > > Subject: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - > OF > > > - SF > > > > > > Richard, > > > > > > Yes I know I was mixing data and mechanism-to-access-data. > > > Still I believe the major point to be correct. In many parts of the > > > world there are already mechanisms (associated with Local Number > > > Portability) to determine ownership of an E.164 number, hence use of > > > ENUM for this purpose alone, will be unnecessary. > > > > > > To be clear, I believe that providing access via Infrastructure ENUM > > > to LNP information may be very helpful; but only if Infrastructure > > > ENUM provides more than just this. > > > If an Infrastructure ENUM query can combine (a) determination of > the > > > entity providing service to the destination, (b) determination of > the > > > corresponding LRN, if one exists, and (c) mapping of the routable > > > number (either the number originally indicated, or the LRN) to a > Layer > > > 5 "point of ingress" specified by the entity providing service to > the > > > destination; then Infrastructure ENUM is quite a handy mechanism. > If > > > all it does is (a) then I don't need it. > > > > > > But in the end this is neither here nor there. I am not wedded to > any > > > specific technology, I just need workable solutions to real business > > > problems. > > > > > > Tim > > > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, May 24, 2006 4:38 PM > > > To: timothy.dwight@verizon.com; timothy.dwight@verizon.com; Michael > > > Hammer (mhammer); Brian Rosen; Francois D. Menard; Khan, Sohel Q > > > [CTO]; David Meyer; speermint@ietf.org > > > Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture - LF - > OF > > > - SF > > > > > > Tim, > > > > > > thanx for your reply, you are raising some important issues. > > > Since it is already midnight here, I will reply to it in detail > > > tomorrow > > > > > > I am also working on a more detailed analysis and a draft which will > > > require even some more time. > > > > > > Just a quick one: > > > > > > >In some parts of the world the function provided by "option > > > 2" usage of > > > >Infrastructure ENUM could be achieved in other ways (e.g., > > > the LERG and > > > >NPDB in North America) so in those cases Infrastructure ENUM > > > might be a > > > >superfluous concept; but if that's the right technical > > > answer so be it. > > > > > > Yes and no ;-) > > > You are mixing up here the Registry and the ENUM DNS. > > > The Registry is the LERG and NPDB (or is derived from), the ENUM DNS > > > is the equivalent on IP of the SCP in the PSTN where the date is > > > downloaded to. > > > > > > Richard > > > > > > > > > ________________________________ > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > Gesendet: Mi 24.05.2006 23:00 > > > An: Stastny Richard; timothy.dwight@verizon.com; 'Michael Hammer > > > (mhammer)'; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q > > > [CTO]'; 'David Meyer'; speermint@ietf.org > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - > OF > > > - SF > > > > > > > > > > > > Richard, > > > > > > Thank you for the clarification. I understand the distinction you > are > > > making. > > > > > > My objective is to be able to translate a destination identifier > > > (E.164 number of alphanumeric AoR) into the address of a Layer 5 > > > entity designated by the organization providing service to the > called > > > party. With infrastructure/carrier ENUM I could do this (as > described > > > in your Option 1), but because ENUM is specific to E.164 numbers it > > > would only work for E.164 -formatted destination identifiers. > > > > > > In pictures, your Option 2 seems to me to imply the following: > > > > > > +----------------+ +----------+ > > > E.164 | infrastructure | serving | identify > > > | network > > > ingress > > > destination -->| ENUM |---> carrier --->| ingress > > > |---> point > > > specified > > > identifier | (option 2) | identity | point | > by > > > serving carrier > > > +----------------+ ^ +----------+ > > > | > > > +----------------+ | > > > non-E.164 | map domain in | | > > > Destination -->| URI to carrier |--------+ > > > Identifier | identity | > > > +----------------+ > > > > > > In some parts of the world the function provided by "option 2" usage > > > of Infrastructure ENUM could be achieved in other ways (e.g., the > LERG > > > and NPDB in North America) so in those cases Infrastructure ENUM > might > > > be a superfluous concept; but if that's the right technical answer > so > > > be it. > > > > > > The "identify ingress point" function would need to be defined. I > > > would like it to consider the specified destination (in addition to > > > the carrier providing service to that destination); and I would like > > > the procedures to be such that the serving carrier controls (in a > > > reasonably dynamic > > > way) the point at which traffic destined to a particular > destination, > > > enters his network. If those requirements can be met, I think this > > > approach is workable. > > > > > > Its biggest drawback is that it precludes a solution ("option 1" > usage > > > of Infrastructure ENUM) that is sufficient for the majority of > today's > > > needs. > > > It optimizes for a problem that will exist in the future at the > > > expense of solving problems that exist today. I realize that > solving > > > today's problems may not be SPEERMINT's focus, or (arguably) even > > > within its charter, but I would hate to see recommendations from > > > SPEERMINT preclude or significantly delay solving them. > > > > > > Suppose we did something like this: > > > > > > +----------+ [pseudo +----------------+ > > > non-E.164 | identify | or real] | infrastructure > > > | network > > > ingress > > > destination -->| "pseudo" |---> E.164 --->| ENUM > > > |---> point > > > specified > > > identifier | E.164 | number | (option 1) | > by > > > serving carrier > > > +----------+ +----------------+ > > > > > > We could let the ENUM working group define Infrastructure ENUM as > > > described in your Option 1 (which is as you know already > commercially > > > available from a few sources) and SPEERMINT could define the > "identify > > > pseudo E.164" function that in my diagram feeds into it. This > > > function might be as simple as mapping the domain part of the URI to > > > an E.164 number uniquely associated with the network providing > service > > > to the specified destination. Unless this is a lot harder than it > > > seems, this shouldn't keep us busy too long :-) > > > > > > > > > Tim > > > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, May 24, 2006 11:16 AM > > > To: timothy.dwight@verizon.com; Michael Hammer (mhammer); > > > Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David > > > Meyer; speermint@ietf.org > > > Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture - > > > LF - OF - SF > > > > > > Tim, > > > > > > >> ... the basic idea of Infrastructure ENUM (which will be used for > > > >> service providers is to provide a domain name in a SIP URI =3D = a > > > >> service provider ID > > > >(SPID) > > > > > > >At the risk of asking an off-topic question (realizing that > > > ENUM is not > > > >within scope for SPEERMINT), can I ask where the idea that > > > >Infrastructure ENUM queries return SPIDs, comes from? It is > > > my intent > > > >to provide a point of interconnection to be used by the requesting > > > >entity to hand to me a call to the specified number. I do > > > not intend > > > >that the only meaningful part of the URI returned from the > > > ENUM query, > > > >be > > > the domain name. > > > > > > thank you for raising this important point. I tried to raise > > > this some time ago, but got no clear answer > > > > > > Currently there exist two lines of thought about the usage of > > > Infrastructure (and also Carrier ENUM in private trees) > > > > > > 1. Put in ENUM the ingress point(s) e.g. > > > sip:+43xxxx@sbc4711.provider.net 2. > > > Put in ENUM the AoR only: e.g. sip:+43xxx@provider.net > > > (provider.net is what I meant with SPID) > > > > > > Most currently prefer option 1, especially in private ENUM trees. > > > > > > IMHO this is the wrong approach: > > > > > > There should be a clear separation (and it is in the charter) > > > between ENUM and SPEERMINT SPEERMINT peering MUST be able to > > > work standalone and without ENUM. > > > > > > Option 1 assumes also that the user is entering ALWAYS an > > > E.164 number as identifier. > > > > > > But what if he is entering an AoR? > > > > > > SPEEMINT peering MUST be able to resolve this too so you need > > > to find the ingress point independant of ENUM e.g. via RFC3263. > > > > > > If this MUST be possible, why not enter in (any) ENUM just > > > the AoR, if you must be able to resolve the AoR anyway? > > > > > > Otherwise you need to manage two mappings separate 1. the > > > E.164 to ingress point 2. the AoR mapping to ingress point > > > > > > this is not a good idea > > > > > > This is the reason why I would prefer to enter in ENUM AoRs > > > only the user part in ENUM is always the E.164 number (for > > > privacy reasons) the domain part is the SPID, which is mapped > > > later to find the ingress point > > > > > > the calling user may then also use an alis AoR such as > > > sip:name@provider.net > > > > > > regards > > > > > > Richard > > > > > > > > > > > > ________________________________ > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > Gesendet: Mi 24.05.2006 16:46 > > > An: Stastny Richard; 'Michael Hammer (mhammer)'; 'Brian > > > Rosen'; 'Francois D. > > > Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; speermint@ietf.org > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - > > > LF - OF - SF > > > > > > > > > > > > Stastny, Richard said: > > > > > > > ... the basic idea of Infrastructure ENUM (which will be used for > > > > service providers is to provide a domain name in a SIP URI > > > =3D a service > > > > provider ID > > > (SPID) > > > > > > At the risk of asking an off-topic question (realizing that > > > ENUM is not within scope for SPEERMINT), can I ask where the > > > idea that Infrastructure ENUM queries return SPIDs, comes > > > from? It is my intent to provide a point of interconnection > > > to be used by the requesting entity to hand to me a call to > > > the specified number. I do not intend that the only > > > meaningful part of the URI returned from the ENUM query, be > > > the domain name. > > > > > > tim > > > > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 11:42:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjeSI-00032R-S2; Fri, 26 May 2006 11:42:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjeSH-0002vB-CG for speermint@ietf.org; Fri, 26 May 2006 11:42:25 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjeSF-0008K0-0x for speermint@ietf.org; Fri, 26 May 2006 11:42:25 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 26 May 2006 08:42:22 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,177,1146466800"; d="scan'208"; a="29023265:sNHT24674252" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4QFgMTL016785; Fri, 26 May 2006 11:42:22 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 May 2006 11:42:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Fri, 26 May 2006 11:42:20 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301848101@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaA1rSoOHPGUPYsQwGxqq1E92SjnQAA1iqw From: "Michael Hammer \(mhammer\)" To: "Otmar Lendl" X-OriginalArrivalTime: 26 May 2006 15:42:22.0013 (UTC) FILETIME=[FA797ED0:01C680DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: "Khan, Sohel Q \[CTO\]" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I don't think the approaches each of us is suggesting are mutually exclusive. In your case, you are saying here is all the info you need, go ahead and send your INVITEs. In my case, it is adding an added level of indirection. What is advertised in DNS is a contact point to find out further information. After subscribing to that pointer, you get a tailored response of where and how to send your INVITEs. Both can co-exist. It all boils down to how a domain wants to set itself up and what information to reveal initially versus later as the peer reveals more information (authentication) about itself. Mike > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at]=20 > Sent: Friday, May 26, 2006 11:12 AM > To: Michael Hammer (mhammer) > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 >=20 > Michael, >=20 > On 2006/05/25 18:05, "Michael Hammer (mhammer)"=20 > wrote: > >=20 > > If an address is advertized in public ENUM or DNS, then it=20 > ought not=20 > > be unreachable due to use of private networks or NATs, which is the=20 > > basis for some of your arguments about why not SIP. >=20 > We're moving a bit into ENUM WG turf here, but anyway. >=20 > We're in a bit of a dilemma here regarding infrastructure ENUM: >=20 > On a national level it's manageable to build a private DNS=20 > which only proper (whatever than means) operators can access.=20 > Thus you can build a system that has the feature "if you can=20 > see the URI, then you can reach it". >=20 > On an international level I consider this to be impossible.=20 > The definitions about who is a proper carrier or not will=20 > vary a great deal and I doubt that a big incumbent in one=20 > country will want to directly talk to an upstart VoIP=20 > operator two continents away.=20 > Keeping that tree hidden from public view is quite impossible=20 > if you consider the scope of the legitimate readers.=20 > Consistent selective visibility in a distributed DNS tree is=20 > very tricky. >=20 > [e164.info managed to do so on a small scale, but they use a=20 > central DB. I doubt that you can scale up their system to=20 > worldwide, non-centralized one.] >=20 > My conclusion from that is that >=20 > * infrastructure ENUM will be public (if it wants to enable more than > just national peerings). >=20 > * Thus the reachability assumption will have to yield. >=20 > I wish it weren't so. But I haven't found a way to avoid this=20 > conclusion. >=20 > Do you see other options? >=20 > > My thinking was that one would need to progress through a series of=20 > > steps/functions where the bootstrap steps are very public, but the=20 > > later steps depend on the previous step enabling it. The=20 > chicken or=20 > > egg problem shouldn't occur for first steps. >=20 > That's why we put the bootstrapping steps into the DNS. Any=20 > other system SPEERMINT will come up with, e.g. some=20 > SUBSCRIBE/NOTIFY would fit in very nicely: the domain policy=20 > the can reference this framework as the requirement to reach=20 > the destination. >=20 > > (I do understand your model > > where you advertise what is only reachable by a few, but then it is=20 > > working as you intended with selective unreachability being part of=20 > > your > > design.) >=20 > As I see the market right now, we already have a very=20 > selective reachability on the SIP layer between VoIP operators. >=20 > I can't see a way to move the state of affairs to=20 > "interconnection on SIP basis between all commercial=20 > VoIP-operators worldwide" without either >=20 > * building a SIP routing protocol complete with transit networks > (the BGP model) >=20 > or=20 >=20 > * require the possibility of direct connections between all > operators worldwide.=20 > Determining whether the caller from halfway around the globe > is a legitimate operator is massively difficult, thus we > end running open servers. (the email model) >=20 > Thus I think selective reachability on SIP will stay with us=20 > for the medium term. >=20 > > Hopefully, any delays to call setup occur only because of initial=20 > > contact to previously unknown domains. For, previously contacted=20 > > domains or for federations that use a central SIP proxy or some=20 > > interconnect SIP fabric, the call can be quickly handed to=20 > the heavily=20 > > used local contact point for that federation, since they=20 > were learned=20 > > previous to the call. >=20 > That sounds good. >=20 > > Anyway, it may be possible through configuration to address=20 > both ways,=20 > > with some heuristic to guide when to transition from the "policy is=20 > > simple" approach to the "policy is complex" approach. >=20 > Even if the policy record just states "this is a carrier URI,=20 > calls must use RFC-SPEERMINT-SUBSCRIPTIONS", this is helpful=20 > for callers. >=20 > I see domain policies as the meta-protocol to bootstrap=20 > various other peering mechanisms.=20 >=20 > The adoption of my draft thus does not preclude further work=20 > in speermint. Quite the contrary. >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 11:51:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjeaT-0001Yi-Cf; Fri, 26 May 2006 11:50:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjeaS-0001YN-Ao for speermint@ietf.org; Fri, 26 May 2006 11:50:52 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjeaR-0000cE-G9 for speermint@ietf.org; Fri, 26 May 2006 11:50:52 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 26 May 2006 11:50:51 -0400 X-IronPort-AV: i="4.05,177,1146456000"; d="scan'208"; a="89561538:sNHT40749112" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4QFopTL018511; Fri, 26 May 2006 11:50:51 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 May 2006 11:50:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Location Function in SPEERMINT Date: Fri, 26 May 2006 11:50:49 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301848109@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Location Function in SPEERMINT Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAATumxgAG4BNwABEZoVAADQ2DIAAC1z/9AAGrFeAACZ2pfQABju7wACHfcEAAAbB9IAAK1HH6AAC9BtAAAGOAdAAAMvVgACTEanAAAMf18AAA1j4AAAEyrIA= From: "Michael Hammer \(mhammer\)" To: "James McEachern" , X-OriginalArrivalTime: 26 May 2006 15:50:50.0963 (UTC) FILETIME=[29D51A30:01C680DC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 052f5f7988f6d35f983a2680181d544b Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I think I have lost track of what "it" is. I don't think "it" is the ability to identify a proxy that a peer should use based on location. "It" may be the ability to identify a proxy that a peer should use based on the peer identity or affiliation (federation). "Location" has geographic baggage when perhaps selective "discovery" is really what is meant. Please correct me as I may have gotten disoriented with the different mail threads. Mike > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com]=20 > Sent: Friday, May 26, 2006 11:16 AM > To: Michael Hammer (mhammer); speermint@ietf.org > Subject: RE: [Speermint] Location Function in SPEERMINT >=20 > So are you saying that it should be a requirement? >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, May 26, 2006 10:52 AM > To: McEachern, James [CAR:5N00:EXCH]; Reinaldo Penno; Stastny=20 > Richard; timothy.dwight@verizon.com;=20 > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard;=20 > Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > Subject: RE: [Speermint] Location Function in SPEERMINT >=20 > Distance is dead IF the proxy does not have strong ties to a=20 > media anchor point. If there is such a media anchor point,=20 > then choosing ones that are close to calling and called=20 > parties will aid in finding shortest routes between parties. >=20 > However, I am not advocating for or against such media=20 > anchors, just simply recognizing that they may exist=20 > depending on a domain's architecture. >=20 > There may be other reasons that peers are directed to one=20 > proxy over another. It is useful for the domain to designate=20 > which proxies peers should use. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: James McEachern [mailto:jmce@nortel.com] > > Sent: Friday, May 26, 2006 10:44 AM > > To: Reinaldo Penno; Stastny Richard; > > timothy.dwight@verizon.com; Michael Hammer (mhammer);=20 > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan,=20 > > Sohel Q [CTO]; David Meyer; speermint@ietf.org > > Subject: RE: [Speermint] Location Function in SPEERMINT > >=20 > > >This tells you the SIP proxy to be contacted. It does not > > tell you if > > >this the closest Sip Proxy handling @example.com users. It=20 > also does=20 > > >not tell you if it is the closest proxy to the callee. > >=20 > > Is the ability to "identify the closest proxy" a requirement for=20 > > Speermint? Many people have pointed out that distance is=20 > dead, or at=20 > > least should be, so it isn't clear to me that we really care. The=20 > > Requirements and Terminology draft doesn't explicitly say, but my=20 > > reading of section 5.2 implies this is not a requirement. > >=20 > > That having been said, I don't necessarily have strong views either=20 > > way. I'd just like to be clear on whether or not it is a=20 > requirement. > >=20 > > Jim > >=20 > >=20 > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Thursday, May 25, 2006 5:00 PM > > To: Stastny Richard; timothy.dwight@verizon.com; Michael Hammer=20 > > (mhammer); timothy.dwight@verizon.com; Brian Rosen; Francois D.=20 > > Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > > Subject: RE: [Speermint] Location Function in SPEERMINT > >=20 > > I believe it is enough. You could refine it but I might sure of the=20 > > benefits. Maybe this problem was already solved somewhere=20 > and I'm not=20 > > aware. > >=20 > > For example, The UAs would care. > >=20 > > >From RFC3263 > >=20 > > ;; Priority Weight Port Target > > IN SRV 0 1 5060 server1.example.com > > IN SRV 0 2 5060 server2.example.com > >=20 > > This tells you the SIP proxy to be contacted. It does not=20 > tell you if=20 > > this the closest Sip Proxy handling @example.com users. It=20 > also does=20 > > not tell you if it is the closest proxy to the callee. > >=20 > > In the case of a carriers providing VoIP service to a user, if this=20 > > provider A peers with provider B in two different=20 > locations, which one=20 > > to choose to send to forward the call? > >=20 > > Regards, > >=20 > > Reinaldo > >=20 > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, May 25, 2006 1:52 PM > > > To: Reinaldo Penno; timothy.dwight@verizon.com; Michael Hammer > > (mhammer); > > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > > Sohel Q > > > [CTO]; David Meyer; speermint@ietf.org > > > Subject: Re: [Speermint] Location Function in SPEERMINT > > >=20 > > > Reinaldo said: > > > >That's maybe one of the most important issues. This could be > > complicated > > > >by the geographically dispersed networks with several=20 > entry points. > > > >Although this might be an interesting problem it might be > > a rathole. > > >=20 > > > So you say RFC 3263 is not enough, something is missing? > > > e.g. the geographic location of originating and terminating > > --- what? > > >=20 > > > -SIP proxy? who cares > > > -SBC? > > > -UA? > > >=20 > > > So we are again dealing with SBCs, in this case the=20 > geo-location of > > these > > > -- rats, holes ;-) > > >=20 > > > Richard > > >=20 > > >=20 > > > ________________________________ > > >=20 > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Gesendet: Do 25.05.2006 22:37 > > > An: Stastny Richard; timothy.dwight@verizon.com; Michael Hammer > > (mhammer); > > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > > Sohel Q > > > [CTO]; David Meyer; speermint@ietf.org > > > Betreff: RE: [Speermint] Location Function in SPEERMINT > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, May 25, 2006 1:26 PM > > > > To: timothy.dwight@verizon.com; Michael Hammer (mhammer);=20 > > > > timothy.dwight@verizon.com; Brian Rosen; Francois D.=20 > Menard; Khan, > > > Sohel Q > > > > [CTO]; David Meyer; speermint@ietf.org > > > > Subject: [Speermint] Location Function in SPEERMINT > > > > > > > > Hi all, > > > > > > > > sorry, but I am only able to reply with a short > > statement, because I > > > am > > > > on vacation and have only limited time and bandwitdh (GPRS) > > > > > > > > First, I consider this discussion regarding Infrastructure ENUM, > > LERG > > > and > > > > LNP > > > > important, but in the wrong WG. It should be discussed=20 > in ENUM. WG > > and > > > > not in SPEERMINT > > > > > > > > SPEERMINT is only dealing with Call Routing Data (CRD), which is > > > defined > > > > as the OUTPUT of ENUM or some other means. > > > > > > > > This implies, that the location function (LF) defined in the=20 > > > > achitecture draft happens AFTER an ENUM query and > > therefore cannot > > > > be the part of the LF. > > > > > > > > The LF can only involve the location of the destination=20 > "network" > > > > as defined in SPEERMINT by the use of CRD (which is > > basically a SIP > > > > URI because we are currently talking only SIP in SPEERMINT) > > > > > > > > Of course SPEERMINT needs to define what it considers > > CRD, and AoR > > > > or the ingress point of a network. > > > > > > > > BUT then SPEERMINT needs also to define how the ingress > > point of a > > > > "network" is LOCATED given a SIP AoR. > > > [[Reinaldo]] > > >=20 > > > That's maybe one of the most important issues. This could be > > complicated > > > by the geographically dispersed networks with several=20 > entry points. > > > Although this might be an interesting problem it might be=20 > a rathole. > > >=20 > > >=20 > > > > > > > > Richard > > > > > > > > > > > > ________________________________ > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > Gesendet: Do 25.05.2006 20:17 > > > > An: 'Michael Hammer (mhammer)'; > > timothy.dwight@verizon.com; Stastny > > > > Richard; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, > > Sohel Q [CTO]'; > > > > 'David Meyer'; speermint@ietf.org > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering=20 > Architecture - LF - > > OF > > > - SF > > > > > > > > > > > > > > > > Michael Hammer said: > > > > > > > > > Tim, > > > > > > > > > > The LERG and LNP databases are intrinsically tied to > > the operation > > > of > > > > the > > > > TDM > > > > > infrastructure. Any design that perpatuates these=20 > systems when > > > their > > > > reason > > > > > for being (TDM) goes away is a faulty design. > > > > > > > > OK with me. I only meant to point out that right now I > > have these > > > > capabilities, so recreating them isn't a high priority. > > > > > > > > > > > > > > > > > > DNS and ENUM provides the equivalent information and > > mechanisms to > > > do > > > > what > > > > is > > > > > needed in the IP domain. As such, a design that makes > > dependencies > > > on > > > > legacy > > > > > systems is deficient. I wouldn't support such a kludge. > > > > > > > > Fine. > > > > > > > > I'm a big fan of IP-domain solutions. Specifically=20 > Infrastructure > > > ENUM > > > > looks really handy; my point before was that it's=20 > moreso when used > > in > > > what > > > > Richard called "option 1". The alternative ("option 2") only > > > replicates > > > > the > > > > "kludge" to which I already have access. > > > > > > > > And to be fair to Richard, he did point out (subtly) that > > the latter > > > claim > > > > is a bit myopic. There are existing means by which=20 > VSPs can gain > > > access > > > > to > > > > number portability information relative to national=20 > destinations. > > > They > > > > don't have such access, at least not easily and not > > universally, to > > > number > > > > portability information relative to international > > destinations. If > > > that > > > > could be provided by Infrastructure ENUM (either "option 1" or > > "option > > > 2") > > > > it would be useful and would not simply replicate existing > > > capabilities. > > > > > > > > Bottom line, both options defined by Richard, would add value. > > Option > > > 1 > > > > adds more value but is specific to destinations > > identified by E.164 > > > > numbers or URIs with imbedded E.164 numbers. Which is > > the problem > > > > closest > > to > > > > hand. > > > > > > > > > > > > > > > > > > That said, if there are backward compatibilities during the > > > transition, > > > > where > > > > > some information just happens to be known by external systems, > > such > > > as > > > > you > > > > suggest > > > > > below, I don't see that as a problem. I am just wary > > of ending up > > > with > > > > two > > > > > systems in the end when one would do. > > > > > > > > Isn't it inevitable that for some time, both will=20 > exist? Just as > > the > > > GSTN > > > > and VoIP will coexist for some time, so will their supporting=20 > > > > infrastructure. > > > > > > > > Don't get me wrong. I'm not saying "because I have an=20 > SS7 -based > > > solution > > > > to LNP I don't need an IP -based solution". All I'm > > saying is that > > > when > > > > given the option of using Infrastructure ENUM to=20 > recreate (and in > > the > > > case > > > > of international destinations, extend) the capability I already > > have, > > > and > > > > using it to do that and more, I'm inclined to prefer the latter. > > > > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > > Sent: Wednesday, May 24, 2006 6:19 PM > > > > > To: 'Stastny Richard'; timothy.dwight@verizon.com;=20 > > > > > timothy.dwight@verizon.com; Michael Hammer (mhammer); 'Brian > > Rosen'; > > > > > 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer';=20 > > > > > speermint@ietf.org > > > > > Subject: RE: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > OF > > > > > - SF > > > > > > > > > > Richard, > > > > > > > > > > Yes I know I was mixing data and mechanism-to-access-data. > > > > > Still I believe the major point to be correct. In=20 > many parts of > > the > > > > > world there are already mechanisms (associated with=20 > Local Number > > > > > Portability) to determine ownership of an E.164 number, > > hence use > > of > > > > > ENUM for this purpose alone, will be unnecessary. > > > > > > > > > > To be clear, I believe that providing access via=20 > Infrastructure > > ENUM > > > > > to LNP information may be very helpful; but only if > > Infrastructure > > > > > ENUM provides more than just this. > > > > > If an Infrastructure ENUM query can combine (a) > > determination of > > > the > > > > > entity providing service to the destination, (b) > > determination of > > > the > > > > > corresponding LRN, if one exists, and (c) mapping of > > the routable > > > > > number (either the number originally indicated, or=20 > the LRN) to a > > > Layer > > > > > 5 "point of ingress" specified by the entity providing > > service to > > > the > > > > > destination; then Infrastructure ENUM is quite a handy > > mechanism. > > > If > > > > > all it does is (a) then I don't need it. > > > > > > > > > > But in the end this is neither here nor there. I am > > not wedded to > > > any > > > > > specific technology, I just need workable solutions to real > > business > > > > > problems. > > > > > > > > > > Tim > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Wednesday, May 24, 2006 4:38 PM > > > > > To: timothy.dwight@verizon.com; timothy.dwight@verizon.com; > > Michael > > > > > Hammer (mhammer); Brian Rosen; Francois D. Menard; > > Khan, Sohel Q > > > > > [CTO]; David Meyer; speermint@ietf.org > > > > > Subject: Re: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > OF > > > > > - SF > > > > > > > > > > Tim, > > > > > > > > > > thanx for your reply, you are raising some important issues. > > > > > Since it is already midnight here, I will reply to it=20 > in detail=20 > > > > > tomorrow > > > > > > > > > > I am also working on a more detailed analysis and a=20 > draft which > > will > > > > > require even some more time. > > > > > > > > > > Just a quick one: > > > > > > > > > > >In some parts of the world the function provided by "option > > > > > 2" usage of > > > > > >Infrastructure ENUM could be achieved in other ways (e.g., > > > > > the LERG and > > > > > >NPDB in North America) so in those cases Infrastructure ENUM > > > > > might be a > > > > > >superfluous concept; but if that's the right technical > > > > > answer so be it. > > > > > > > > > > Yes and no ;-) > > > > > You are mixing up here the Registry and the ENUM DNS. > > > > > The Registry is the LERG and NPDB (or is derived=20 > from), the ENUM > > DNS > > > > > is the equivalent on IP of the SCP in the PSTN where > > the date is > > > > > downloaded to. > > > > > > > > > > Richard > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > > Gesendet: Mi 24.05.2006 23:00 > > > > > An: Stastny Richard; timothy.dwight@verizon.com; > > 'Michael Hammer > > > > > (mhammer)'; 'Brian Rosen'; 'Francois D. Menard';=20 > 'Khan, Sohel Q=20 > > > > > [CTO]'; 'David Meyer'; speermint@ietf.org > > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > OF > > > > > - SF > > > > > > > > > > > > > > > > > > > > Richard, > > > > > > > > > > Thank you for the clarification. I understand the > > distinction you > > > are > > > > > making. > > > > > > > > > > My objective is to be able to translate a destination=20 > identifier > > > > > (E.164 number of alphanumeric AoR) into the address of > > a Layer 5 > > > > > entity designated by the organization providing service to the > > > called > > > > > party. With infrastructure/carrier ENUM I could do this (as > > > described > > > > > in your Option 1), but because ENUM is specific to=20 > E.164 numbers > > it > > > > > would only work for E.164 -formatted destination identifiers. > > > > > > > > > > In pictures, your Option 2 seems to me to imply the following: > > > > > > > > > > +----------------+ +----------+ > > > > > E.164 | infrastructure | serving | identify > > > > > | network > > > > > ingress > > > > > destination -->| ENUM |---> carrier --->| ingress > > > > > |---> point > > > > > specified > > > > > identifier | (option 2) | identity | point | > > > by > > > > > serving carrier > > > > > +----------------+ ^ +----------+ > > > > > | > > > > > +----------------+ | > > > > > non-E.164 | map domain in | | > > > > > Destination -->| URI to carrier |--------+ > > > > > Identifier | identity | > > > > > +----------------+ > > > > > > > > > > In some parts of the world the function provided by "option 2" > > usage > > > > > of Infrastructure ENUM could be achieved in other ways > > (e.g., the > > > LERG > > > > > and NPDB in North America) so in those cases=20 > Infrastructure ENUM > > > might > > > > > be a superfluous concept; but if that's the right > > technical answer > > > so > > > > > be it. > > > > > > > > > > The "identify ingress point" function would need to be > > defined. I > > > > > would like it to consider the specified destination=20 > (in addition > > to > > > > > the carrier providing service to that destination);=20 > and I would > > like > > > > > the procedures to be such that the serving carrier > > controls (in a > > > > > reasonably dynamic > > > > > way) the point at which traffic destined to a particular > > > destination, > > > > > enters his network. If those requirements can be met, I think > > this > > > > > approach is workable. > > > > > > > > > > Its biggest drawback is that it precludes a solution=20 > ("option 1" > > > usage > > > > > of Infrastructure ENUM) that is sufficient for the majority of > > > today's > > > > > needs. > > > > > It optimizes for a problem that will exist in the=20 > future at the=20 > > > > > expense of solving problems that exist today. I realize that > > > solving > > > > > today's problems may not be SPEERMINT's focus, or > > (arguably) even > > > > > within its charter, but I would hate to see > > recommendations from > > > > > SPEERMINT preclude or significantly delay solving them. > > > > > > > > > > Suppose we did something like this: > > > > > > > > > > +----------+ [pseudo +----------------+ > > > > > non-E.164 | identify | or real] | infrastructure > > > > > | network > > > > > ingress > > > > > destination -->| "pseudo" |---> E.164 --->| ENUM > > > > > |---> point > > > > > specified > > > > > identifier | E.164 | number | (option 1) | > > > by > > > > > serving carrier > > > > > +----------+ +----------------+ > > > > > > > > > > We could let the ENUM working group define > > Infrastructure ENUM as > > > > > described in your Option 1 (which is as you know already > > > commercially > > > > > available from a few sources) and SPEERMINT could define the > > > "identify > > > > > pseudo E.164" function that in my diagram feeds into=20 > it. This=20 > > > > > function might be as simple as mapping the domain part > > of the URI > > to > > > > > an E.164 number uniquely associated with the network providing > > > service > > > > > to the specified destination. Unless this is a lot > > harder than it > > > > > seems, this shouldn't keep us busy too long :-) > > > > > > > > > > > > > > > Tim > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Wednesday, May 24, 2006 11:16 AM > > > > > To: timothy.dwight@verizon.com; Michael Hammer=20 > (mhammer); Brian=20 > > > > > Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer;=20 > > > > > speermint@ietf.org > > > > > Subject: Re: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > > > OF - SF > > > > > > > > > > Tim, > > > > > > > > > > >> ... the basic idea of Infrastructure ENUM (which=20 > will be used > > for > > > > > >> service providers is to provide a domain name in a > > SIP URI =3D a > > > > > >> service provider ID > > > > > >(SPID) > > > > > > > > > > >At the risk of asking an off-topic question (realizing that > > > > > ENUM is not > > > > > >within scope for SPEERMINT), can I ask where the idea that=20 > > > > > >Infrastructure ENUM queries return SPIDs, comes from? It is > > > > > my intent > > > > > >to provide a point of interconnection to be used by the > > requesting > > > > > >entity to hand to me a call to the specified number. I do > > > > > not intend > > > > > >that the only meaningful part of the URI returned from the > > > > > ENUM query, > > > > > >be > > > > > the domain name. > > > > > > > > > > thank you for raising this important point. I tried to > > raise this > > > > > some time ago, but got no clear answer > > > > > > > > > > Currently there exist two lines of thought about the usage of=20 > > > > > Infrastructure (and also Carrier ENUM in private trees) > > > > > > > > > > 1. Put in ENUM the ingress point(s) e.g. > > > > > sip:+43xxxx@sbc4711.provider.net 2. > > > > > Put in ENUM the AoR only: e.g. sip:+43xxx@provider.net=20 > > > > > (provider.net is what I meant with SPID) > > > > > > > > > > Most currently prefer option 1, especially in private > > ENUM trees. > > > > > > > > > > IMHO this is the wrong approach: > > > > > > > > > > There should be a clear separation (and it is in the charter)=20 > > > > > between ENUM and SPEERMINT SPEERMINT peering MUST be > > able to work > > > > > standalone and without ENUM. > > > > > > > > > > Option 1 assumes also that the user is entering ALWAYS an > > > > > E.164 number as identifier. > > > > > > > > > > But what if he is entering an AoR? > > > > > > > > > > SPEEMINT peering MUST be able to resolve this too so > > you need to > > > > > find the ingress point independant of ENUM e.g. via RFC3263. > > > > > > > > > > If this MUST be possible, why not enter in (any) ENUM=20 > just the=20 > > > > > AoR, if you must be able to resolve the AoR anyway? > > > > > > > > > > Otherwise you need to manage two mappings separate 1. the > > > > > E.164 to ingress point 2. the AoR mapping to ingress point > > > > > > > > > > this is not a good idea > > > > > > > > > > This is the reason why I would prefer to enter in ENUM > > AoRs only > > > > > the user part in ENUM is always the E.164 number (for privacy > > > > > reasons) the domain part is the SPID, which is mapped=20 > later to=20 > > > > > find the ingress point > > > > > > > > > > the calling user may then also use an alis AoR such as=20 > > > > > sip:name@provider.net > > > > > > > > > > regards > > > > > > > > > > Richard > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > > Gesendet: Mi 24.05.2006 16:46 > > > > > An: Stastny Richard; 'Michael Hammer (mhammer)';=20 > 'Brian Rosen';=20 > > > > > 'Francois D. > > > > > Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; > > speermint@ietf.org > > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > > > OF - SF > > > > > > > > > > > > > > > > > > > > Stastny, Richard said: > > > > > > > > > > > ... the basic idea of Infrastructure ENUM (which=20 > will be used > > for > > > > > > service providers is to provide a domain name in a SIP URI > > > > > =3D a service > > > > > > provider ID > > > > > (SPID) > > > > > > > > > > At the risk of asking an off-topic question (realizing > > that ENUM > > > > > is not within scope for SPEERMINT), can I ask where the > > idea that > > > > > Infrastructure ENUM queries return SPIDs, comes from?=20 > It is my=20 > > > > > intent to provide a point of interconnection to be=20 > used by the=20 > > > > > requesting entity to hand to me a call to the specified > > number. I > > > > > do not intend that the only meaningful part of the=20 > URI returned=20 > > > > > from the ENUM query, be the domain name. > > > > > > > > > > tim > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 12:23:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjf5f-0004DC-BO; Fri, 26 May 2006 12:23:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjf5e-0004D7-HW for speermint@ietf.org; Fri, 26 May 2006 12:23:06 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjf5b-0003Uh-IZ for speermint@ietf.org; Fri, 26 May 2006 12:23:06 -0400 Received: from PMelampy [10.0.200.157] by acmepacket.com with ESMTP (SMTPD-9.03) id AB630180; Fri, 26 May 2006 12:22:59 -0400 From: "Patrick Melampy" To: "'Michael Hammer \(mhammer\)'" , "'James McEachern'" , Subject: RE: [Speermint] Location Function in SPEERMINT Date: Fri, 26 May 2006 12:22:59 -0400 Message-ID: <03a301c680e0$a77bb5d0$0202fea9@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAATumxgAG4BNwABEZoVAADQ2DIAAC1z/9AAGrFeAACZ2pfQABju7wACHfcEAAAbB9IAAK1HH6AAC9BtAAAGOAdAAAMvVgACTEanAAAMf18AAA1j4AAAEyrIAAAQ+GAA== In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301848109@xmb-rtp-20b.amer.cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a0a359c89658364740632bd00d43825 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org One of the best arguments for the "composed" SBC is that if your going to need to locate the "closest media anchor", what better way than associating it with a proxy. If the requirement is to NOT manage the media, but rather let natural BGP4 style internetworking mechanisms route the media optimally, then there is no need to bother with identifying a location of a media anchor. So the real issue here in terms of requirements is: Will Carriers be able to use the autonomous system path (AS_PATH) for delivery and routing of media packets from all sources (customers and suppliers) to all sources (customers and suppliers.) Another way to say the same thing more simply, will carriers put all of the signaled media onto the public internet -- as it's the only internetwork available today. If the answer is NO, then there will need to be media anchors and NAT devices. The location of these devices will be important to the efficiency and manageability of the service offering. The signaling and routing components of the SIP network MUST be aware of the media path, as the signaling plane is establishing the media path. This awareness and state suggest that there needs to be a relationship between the signaling plane and media anchor that is understood and close. I'm going to suggest here that the location of the proxy (the nearest proxy) be a substitute for the nearest media anchor point. -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Friday, May 26, 2006 11:51 AM To: James McEachern; speermint@ietf.org Subject: RE: [Speermint] Location Function in SPEERMINT I think I have lost track of what "it" is. I don't think "it" is the ability to identify a proxy that a peer should use based on location. "It" may be the ability to identify a proxy that a peer should use based on the peer identity or affiliation (federation). "Location" has geographic baggage when perhaps selective "discovery" is really what is meant. Please correct me as I may have gotten disoriented with the different mail threads. Mike > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com] > Sent: Friday, May 26, 2006 11:16 AM > To: Michael Hammer (mhammer); speermint@ietf.org > Subject: RE: [Speermint] Location Function in SPEERMINT > > So are you saying that it should be a requirement? > > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, May 26, 2006 10:52 AM > To: McEachern, James [CAR:5N00:EXCH]; Reinaldo Penno; Stastny > Richard; timothy.dwight@verizon.com; > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; > Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > Subject: RE: [Speermint] Location Function in SPEERMINT > > Distance is dead IF the proxy does not have strong ties to a > media anchor point. If there is such a media anchor point, > then choosing ones that are close to calling and called > parties will aid in finding shortest routes between parties. > > However, I am not advocating for or against such media > anchors, just simply recognizing that they may exist > depending on a domain's architecture. > > There may be other reasons that peers are directed to one > proxy over another. It is useful for the domain to designate > which proxies peers should use. > > Mike > > > > -----Original Message----- > > From: James McEachern [mailto:jmce@nortel.com] > > Sent: Friday, May 26, 2006 10:44 AM > > To: Reinaldo Penno; Stastny Richard; > > timothy.dwight@verizon.com; Michael Hammer (mhammer); > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > > Sohel Q [CTO]; David Meyer; speermint@ietf.org > > Subject: RE: [Speermint] Location Function in SPEERMINT > > > > >This tells you the SIP proxy to be contacted. It does not > > tell you if > > >this the closest Sip Proxy handling @example.com users. It > also does > > >not tell you if it is the closest proxy to the callee. > > > > Is the ability to "identify the closest proxy" a requirement for > > Speermint? Many people have pointed out that distance is > dead, or at > > least should be, so it isn't clear to me that we really care. The > > Requirements and Terminology draft doesn't explicitly say, but my > > reading of section 5.2 implies this is not a requirement. > > > > That having been said, I don't necessarily have strong views either > > way. I'd just like to be clear on whether or not it is a > requirement. > > > > Jim > > > > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Thursday, May 25, 2006 5:00 PM > > To: Stastny Richard; timothy.dwight@verizon.com; Michael Hammer > > (mhammer); timothy.dwight@verizon.com; Brian Rosen; Francois D. > > Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > > Subject: RE: [Speermint] Location Function in SPEERMINT > > > > I believe it is enough. You could refine it but I might sure of the > > benefits. Maybe this problem was already solved somewhere > and I'm not > > aware. > > > > For example, The UAs would care. > > > > >From RFC3263 > > > > ;; Priority Weight Port Target > > IN SRV 0 1 5060 server1.example.com > > IN SRV 0 2 5060 server2.example.com > > > > This tells you the SIP proxy to be contacted. It does not > tell you if > > this the closest Sip Proxy handling @example.com users. It > also does > > not tell you if it is the closest proxy to the callee. > > > > In the case of a carriers providing VoIP service to a user, if this > > provider A peers with provider B in two different > locations, which one > > to choose to send to forward the call? > > > > Regards, > > > > Reinaldo > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, May 25, 2006 1:52 PM > > > To: Reinaldo Penno; timothy.dwight@verizon.com; Michael Hammer > > (mhammer); > > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > > Sohel Q > > > [CTO]; David Meyer; speermint@ietf.org > > > Subject: Re: [Speermint] Location Function in SPEERMINT > > > > > > Reinaldo said: > > > >That's maybe one of the most important issues. This could be > > complicated > > > >by the geographically dispersed networks with several > entry points. > > > >Although this might be an interesting problem it might be > > a rathole. > > > > > > So you say RFC 3263 is not enough, something is missing? > > > e.g. the geographic location of originating and terminating > > --- what? > > > > > > -SIP proxy? who cares > > > -SBC? > > > -UA? > > > > > > So we are again dealing with SBCs, in this case the > geo-location of > > these > > > -- rats, holes ;-) > > > > > > Richard > > > > > > > > > ________________________________ > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Gesendet: Do 25.05.2006 22:37 > > > An: Stastny Richard; timothy.dwight@verizon.com; Michael Hammer > > (mhammer); > > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > > Sohel Q > > > [CTO]; David Meyer; speermint@ietf.org > > > Betreff: RE: [Speermint] Location Function in SPEERMINT > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, May 25, 2006 1:26 PM > > > > To: timothy.dwight@verizon.com; Michael Hammer (mhammer); > > > > timothy.dwight@verizon.com; Brian Rosen; Francois D. > Menard; Khan, > > > Sohel Q > > > > [CTO]; David Meyer; speermint@ietf.org > > > > Subject: [Speermint] Location Function in SPEERMINT > > > > > > > > Hi all, > > > > > > > > sorry, but I am only able to reply with a short > > statement, because I > > > am > > > > on vacation and have only limited time and bandwitdh (GPRS) > > > > > > > > First, I consider this discussion regarding Infrastructure ENUM, > > LERG > > > and > > > > LNP > > > > important, but in the wrong WG. It should be discussed > in ENUM. WG > > and > > > > not in SPEERMINT > > > > > > > > SPEERMINT is only dealing with Call Routing Data (CRD), which is > > > defined > > > > as the OUTPUT of ENUM or some other means. > > > > > > > > This implies, that the location function (LF) defined in the > > > > achitecture draft happens AFTER an ENUM query and > > therefore cannot > > > > be the part of the LF. > > > > > > > > The LF can only involve the location of the destination > "network" > > > > as defined in SPEERMINT by the use of CRD (which is > > basically a SIP > > > > URI because we are currently talking only SIP in SPEERMINT) > > > > > > > > Of course SPEERMINT needs to define what it considers > > CRD, and AoR > > > > or the ingress point of a network. > > > > > > > > BUT then SPEERMINT needs also to define how the ingress > > point of a > > > > "network" is LOCATED given a SIP AoR. > > > [[Reinaldo]] > > > > > > That's maybe one of the most important issues. This could be > > complicated > > > by the geographically dispersed networks with several > entry points. > > > Although this might be an interesting problem it might be > a rathole. > > > > > > > > > > > > > > Richard > > > > > > > > > > > > ________________________________ > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > Gesendet: Do 25.05.2006 20:17 > > > > An: 'Michael Hammer (mhammer)'; > > timothy.dwight@verizon.com; Stastny > > > > Richard; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, > > Sohel Q [CTO]'; > > > > 'David Meyer'; speermint@ietf.org > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering > Architecture - LF - > > OF > > > - SF > > > > > > > > > > > > > > > > Michael Hammer said: > > > > > > > > > Tim, > > > > > > > > > > The LERG and LNP databases are intrinsically tied to > > the operation > > > of > > > > the > > > > TDM > > > > > infrastructure. Any design that perpatuates these > systems when > > > their > > > > reason > > > > > for being (TDM) goes away is a faulty design. > > > > > > > > OK with me. I only meant to point out that right now I > > have these > > > > capabilities, so recreating them isn't a high priority. > > > > > > > > > > > > > > > > > > DNS and ENUM provides the equivalent information and > > mechanisms to > > > do > > > > what > > > > is > > > > > needed in the IP domain. As such, a design that makes > > dependencies > > > on > > > > legacy > > > > > systems is deficient. I wouldn't support such a kludge. > > > > > > > > Fine. > > > > > > > > I'm a big fan of IP-domain solutions. Specifically > Infrastructure > > > ENUM > > > > looks really handy; my point before was that it's > moreso when used > > in > > > what > > > > Richard called "option 1". The alternative ("option 2") only > > > replicates > > > > the > > > > "kludge" to which I already have access. > > > > > > > > And to be fair to Richard, he did point out (subtly) that > > the latter > > > claim > > > > is a bit myopic. There are existing means by which > VSPs can gain > > > access > > > > to > > > > number portability information relative to national > destinations. > > > They > > > > don't have such access, at least not easily and not > > universally, to > > > number > > > > portability information relative to international > > destinations. If > > > that > > > > could be provided by Infrastructure ENUM (either "option 1" or > > "option > > > 2") > > > > it would be useful and would not simply replicate existing > > > capabilities. > > > > > > > > Bottom line, both options defined by Richard, would add value. > > Option > > > 1 > > > > adds more value but is specific to destinations > > identified by E.164 > > > > numbers or URIs with imbedded E.164 numbers. Which is > > the problem > > > > closest > > to > > > > hand. > > > > > > > > > > > > > > > > > > That said, if there are backward compatibilities during the > > > transition, > > > > where > > > > > some information just happens to be known by external systems, > > such > > > as > > > > you > > > > suggest > > > > > below, I don't see that as a problem. I am just wary > > of ending up > > > with > > > > two > > > > > systems in the end when one would do. > > > > > > > > Isn't it inevitable that for some time, both will > exist? Just as > > the > > > GSTN > > > > and VoIP will coexist for some time, so will their supporting > > > > infrastructure. > > > > > > > > Don't get me wrong. I'm not saying "because I have an > SS7 -based > > > solution > > > > to LNP I don't need an IP -based solution". All I'm > > saying is that > > > when > > > > given the option of using Infrastructure ENUM to > recreate (and in > > the > > > case > > > > of international destinations, extend) the capability I already > > have, > > > and > > > > using it to do that and more, I'm inclined to prefer the latter. > > > > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > > Sent: Wednesday, May 24, 2006 6:19 PM > > > > > To: 'Stastny Richard'; timothy.dwight@verizon.com; > > > > > timothy.dwight@verizon.com; Michael Hammer (mhammer); 'Brian > > Rosen'; > > > > > 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; > > > > > speermint@ietf.org > > > > > Subject: RE: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > OF > > > > > - SF > > > > > > > > > > Richard, > > > > > > > > > > Yes I know I was mixing data and mechanism-to-access-data. > > > > > Still I believe the major point to be correct. In > many parts of > > the > > > > > world there are already mechanisms (associated with > Local Number > > > > > Portability) to determine ownership of an E.164 number, > > hence use > > of > > > > > ENUM for this purpose alone, will be unnecessary. > > > > > > > > > > To be clear, I believe that providing access via > Infrastructure > > ENUM > > > > > to LNP information may be very helpful; but only if > > Infrastructure > > > > > ENUM provides more than just this. > > > > > If an Infrastructure ENUM query can combine (a) > > determination of > > > the > > > > > entity providing service to the destination, (b) > > determination of > > > the > > > > > corresponding LRN, if one exists, and (c) mapping of > > the routable > > > > > number (either the number originally indicated, or > the LRN) to a > > > Layer > > > > > 5 "point of ingress" specified by the entity providing > > service to > > > the > > > > > destination; then Infrastructure ENUM is quite a handy > > mechanism. > > > If > > > > > all it does is (a) then I don't need it. > > > > > > > > > > But in the end this is neither here nor there. I am > > not wedded to > > > any > > > > > specific technology, I just need workable solutions to real > > business > > > > > problems. > > > > > > > > > > Tim > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Wednesday, May 24, 2006 4:38 PM > > > > > To: timothy.dwight@verizon.com; timothy.dwight@verizon.com; > > Michael > > > > > Hammer (mhammer); Brian Rosen; Francois D. Menard; > > Khan, Sohel Q > > > > > [CTO]; David Meyer; speermint@ietf.org > > > > > Subject: Re: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > OF > > > > > - SF > > > > > > > > > > Tim, > > > > > > > > > > thanx for your reply, you are raising some important issues. > > > > > Since it is already midnight here, I will reply to it > in detail > > > > > tomorrow > > > > > > > > > > I am also working on a more detailed analysis and a > draft which > > will > > > > > require even some more time. > > > > > > > > > > Just a quick one: > > > > > > > > > > >In some parts of the world the function provided by "option > > > > > 2" usage of > > > > > >Infrastructure ENUM could be achieved in other ways (e.g., > > > > > the LERG and > > > > > >NPDB in North America) so in those cases Infrastructure ENUM > > > > > might be a > > > > > >superfluous concept; but if that's the right technical > > > > > answer so be it. > > > > > > > > > > Yes and no ;-) > > > > > You are mixing up here the Registry and the ENUM DNS. > > > > > The Registry is the LERG and NPDB (or is derived > from), the ENUM > > DNS > > > > > is the equivalent on IP of the SCP in the PSTN where > > the date is > > > > > downloaded to. > > > > > > > > > > Richard > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > > Gesendet: Mi 24.05.2006 23:00 > > > > > An: Stastny Richard; timothy.dwight@verizon.com; > > 'Michael Hammer > > > > > (mhammer)'; 'Brian Rosen'; 'Francois D. Menard'; > 'Khan, Sohel Q > > > > > [CTO]'; 'David Meyer'; speermint@ietf.org > > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > OF > > > > > - SF > > > > > > > > > > > > > > > > > > > > Richard, > > > > > > > > > > Thank you for the clarification. I understand the > > distinction you > > > are > > > > > making. > > > > > > > > > > My objective is to be able to translate a destination > identifier > > > > > (E.164 number of alphanumeric AoR) into the address of > > a Layer 5 > > > > > entity designated by the organization providing service to the > > > called > > > > > party. With infrastructure/carrier ENUM I could do this (as > > > described > > > > > in your Option 1), but because ENUM is specific to > E.164 numbers > > it > > > > > would only work for E.164 -formatted destination identifiers. > > > > > > > > > > In pictures, your Option 2 seems to me to imply the following: > > > > > > > > > > +----------------+ +----------+ > > > > > E.164 | infrastructure | serving | identify > > > > > | network > > > > > ingress > > > > > destination -->| ENUM |---> carrier --->| ingress > > > > > |---> point > > > > > specified > > > > > identifier | (option 2) | identity | point | > > > by > > > > > serving carrier > > > > > +----------------+ ^ +----------+ > > > > > | > > > > > +----------------+ | > > > > > non-E.164 | map domain in | | > > > > > Destination -->| URI to carrier |--------+ > > > > > Identifier | identity | > > > > > +----------------+ > > > > > > > > > > In some parts of the world the function provided by "option 2" > > usage > > > > > of Infrastructure ENUM could be achieved in other ways > > (e.g., the > > > LERG > > > > > and NPDB in North America) so in those cases > Infrastructure ENUM > > > might > > > > > be a superfluous concept; but if that's the right > > technical answer > > > so > > > > > be it. > > > > > > > > > > The "identify ingress point" function would need to be > > defined. I > > > > > would like it to consider the specified destination > (in addition > > to > > > > > the carrier providing service to that destination); > and I would > > like > > > > > the procedures to be such that the serving carrier > > controls (in a > > > > > reasonably dynamic > > > > > way) the point at which traffic destined to a particular > > > destination, > > > > > enters his network. If those requirements can be met, I think > > this > > > > > approach is workable. > > > > > > > > > > Its biggest drawback is that it precludes a solution > ("option 1" > > > usage > > > > > of Infrastructure ENUM) that is sufficient for the majority of > > > today's > > > > > needs. > > > > > It optimizes for a problem that will exist in the > future at the > > > > > expense of solving problems that exist today. I realize that > > > solving > > > > > today's problems may not be SPEERMINT's focus, or > > (arguably) even > > > > > within its charter, but I would hate to see > > recommendations from > > > > > SPEERMINT preclude or significantly delay solving them. > > > > > > > > > > Suppose we did something like this: > > > > > > > > > > +----------+ [pseudo +----------------+ > > > > > non-E.164 | identify | or real] | infrastructure > > > > > | network > > > > > ingress > > > > > destination -->| "pseudo" |---> E.164 --->| ENUM > > > > > |---> point > > > > > specified > > > > > identifier | E.164 | number | (option 1) | > > > by > > > > > serving carrier > > > > > +----------+ +----------------+ > > > > > > > > > > We could let the ENUM working group define > > Infrastructure ENUM as > > > > > described in your Option 1 (which is as you know already > > > commercially > > > > > available from a few sources) and SPEERMINT could define the > > > "identify > > > > > pseudo E.164" function that in my diagram feeds into > it. This > > > > > function might be as simple as mapping the domain part > > of the URI > > to > > > > > an E.164 number uniquely associated with the network providing > > > service > > > > > to the specified destination. Unless this is a lot > > harder than it > > > > > seems, this shouldn't keep us busy too long :-) > > > > > > > > > > > > > > > Tim > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Wednesday, May 24, 2006 11:16 AM > > > > > To: timothy.dwight@verizon.com; Michael Hammer > (mhammer); Brian > > > > > Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer; > > > > > speermint@ietf.org > > > > > Subject: Re: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > > > OF - SF > > > > > > > > > > Tim, > > > > > > > > > > >> ... the basic idea of Infrastructure ENUM (which > will be used > > for > > > > > >> service providers is to provide a domain name in a > > SIP URI = a > > > > > >> service provider ID > > > > > >(SPID) > > > > > > > > > > >At the risk of asking an off-topic question (realizing that > > > > > ENUM is not > > > > > >within scope for SPEERMINT), can I ask where the idea that > > > > > >Infrastructure ENUM queries return SPIDs, comes from? It is > > > > > my intent > > > > > >to provide a point of interconnection to be used by the > > requesting > > > > > >entity to hand to me a call to the specified number. I do > > > > > not intend > > > > > >that the only meaningful part of the URI returned from the > > > > > ENUM query, > > > > > >be > > > > > the domain name. > > > > > > > > > > thank you for raising this important point. I tried to > > raise this > > > > > some time ago, but got no clear answer > > > > > > > > > > Currently there exist two lines of thought about the usage of > > > > > Infrastructure (and also Carrier ENUM in private trees) > > > > > > > > > > 1. Put in ENUM the ingress point(s) e.g. > > > > > sip:+43xxxx@sbc4711.provider.net 2. > > > > > Put in ENUM the AoR only: e.g. sip:+43xxx@provider.net > > > > > (provider.net is what I meant with SPID) > > > > > > > > > > Most currently prefer option 1, especially in private > > ENUM trees. > > > > > > > > > > IMHO this is the wrong approach: > > > > > > > > > > There should be a clear separation (and it is in the charter) > > > > > between ENUM and SPEERMINT SPEERMINT peering MUST be > > able to work > > > > > standalone and without ENUM. > > > > > > > > > > Option 1 assumes also that the user is entering ALWAYS an > > > > > E.164 number as identifier. > > > > > > > > > > But what if he is entering an AoR? > > > > > > > > > > SPEEMINT peering MUST be able to resolve this too so > > you need to > > > > > find the ingress point independant of ENUM e.g. via RFC3263. > > > > > > > > > > If this MUST be possible, why not enter in (any) ENUM > just the > > > > > AoR, if you must be able to resolve the AoR anyway? > > > > > > > > > > Otherwise you need to manage two mappings separate 1. the > > > > > E.164 to ingress point 2. the AoR mapping to ingress point > > > > > > > > > > this is not a good idea > > > > > > > > > > This is the reason why I would prefer to enter in ENUM > > AoRs only > > > > > the user part in ENUM is always the E.164 number (for privacy > > > > > reasons) the domain part is the SPID, which is mapped > later to > > > > > find the ingress point > > > > > > > > > > the calling user may then also use an alis AoR such as > > > > > sip:name@provider.net > > > > > > > > > > regards > > > > > > > > > > Richard > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > > Gesendet: Mi 24.05.2006 16:46 > > > > > An: Stastny Richard; 'Michael Hammer (mhammer)'; > 'Brian Rosen'; > > > > > 'Francois D. > > > > > Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; > > speermint@ietf.org > > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > > > OF - SF > > > > > > > > > > > > > > > > > > > > Stastny, Richard said: > > > > > > > > > > > ... the basic idea of Infrastructure ENUM (which > will be used > > for > > > > > > service providers is to provide a domain name in a SIP URI > > > > > = a service > > > > > > provider ID > > > > > (SPID) > > > > > > > > > > At the risk of asking an off-topic question (realizing > > that ENUM > > > > > is not within scope for SPEERMINT), can I ask where the > > idea that > > > > > Infrastructure ENUM queries return SPIDs, comes from? > It is my > > > > > intent to provide a point of interconnection to be > used by the > > > > > requesting entity to hand to me a call to the specified > > number. I > > > > > do not intend that the only meaningful part of the > URI returned > > > > > from the ENUM query, be the domain name. > > > > > > > > > > tim > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 12:35:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjfH8-0006c5-8w; Fri, 26 May 2006 12:34:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjfH6-0006bw-MZ for speermint@ietf.org; Fri, 26 May 2006 12:34:56 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjfH5-0004wQ-Q0 for speermint@ietf.org; Fri, 26 May 2006 12:34:56 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k4QGTkf12309; Fri, 26 May 2006 12:29:47 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Location Function in SPEERMINT Date: Fri, 26 May 2006 12:34:46 -0400 Message-ID: In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301848109@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Location Function in SPEERMINT Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAATumxgAG4BNwABEZoVAADQ2DIAAC1z/9AAGrFeAACZ2pfQABju7wACHfcEAAAbB9IAAK1HH6AAC9BtAAAGOAdAAAMvVgACTEanAAAMf18AAA1j4AAAEyrIAAAVK4MA== From: "James McEachern" To: "Michael Hammer \(mhammer\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 197d13e6eff8b01fadb94b62c6f788ce Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Fair enough - I think I may be losing track of "it" myself. Let me take = a stab at it, and then perhaps we can agree if "it" is a requirement or = not. Possible SPEERMINT requirement: The ability to selectively discover a = specific instance of a proxy/interconnect point for peering. The = criteria used to select the appropriate proxy include: (here I think we = need to make a specific decision for each potential criterion.) - peer identity or affiliation (federation) - location (or distance, or some other suitable related attribute) - other??? Jim -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Friday, May 26, 2006 11:51 AM To: McEachern, James [CAR:5N00:EXCH]; speermint@ietf.org Subject: RE: [Speermint] Location Function in SPEERMINT I think I have lost track of what "it" is. I don't think "it" is the ability to identify a proxy that a peer should use based on location. "It" may be the ability to identify a proxy that a peer should use based on the peer identity or affiliation (federation). "Location" has geographic baggage when perhaps selective "discovery" is really what is meant. Please correct me as I may have gotten disoriented with the different mail threads. Mike > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com]=20 > Sent: Friday, May 26, 2006 11:16 AM > To: Michael Hammer (mhammer); speermint@ietf.org > Subject: RE: [Speermint] Location Function in SPEERMINT >=20 > So are you saying that it should be a requirement? >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, May 26, 2006 10:52 AM > To: McEachern, James [CAR:5N00:EXCH]; Reinaldo Penno; Stastny=20 > Richard; timothy.dwight@verizon.com;=20 > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard;=20 > Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > Subject: RE: [Speermint] Location Function in SPEERMINT >=20 > Distance is dead IF the proxy does not have strong ties to a=20 > media anchor point. If there is such a media anchor point,=20 > then choosing ones that are close to calling and called=20 > parties will aid in finding shortest routes between parties. >=20 > However, I am not advocating for or against such media=20 > anchors, just simply recognizing that they may exist=20 > depending on a domain's architecture. >=20 > There may be other reasons that peers are directed to one=20 > proxy over another. It is useful for the domain to designate=20 > which proxies peers should use. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: James McEachern [mailto:jmce@nortel.com] > > Sent: Friday, May 26, 2006 10:44 AM > > To: Reinaldo Penno; Stastny Richard; > > timothy.dwight@verizon.com; Michael Hammer (mhammer);=20 > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan,=20 > > Sohel Q [CTO]; David Meyer; speermint@ietf.org > > Subject: RE: [Speermint] Location Function in SPEERMINT > >=20 > > >This tells you the SIP proxy to be contacted. It does not > > tell you if > > >this the closest Sip Proxy handling @example.com users. It=20 > also does=20 > > >not tell you if it is the closest proxy to the callee. > >=20 > > Is the ability to "identify the closest proxy" a requirement for=20 > > Speermint? Many people have pointed out that distance is=20 > dead, or at=20 > > least should be, so it isn't clear to me that we really care. The=20 > > Requirements and Terminology draft doesn't explicitly say, but my=20 > > reading of section 5.2 implies this is not a requirement. > >=20 > > That having been said, I don't necessarily have strong views either=20 > > way. I'd just like to be clear on whether or not it is a=20 > requirement. > >=20 > > Jim > >=20 > >=20 > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Thursday, May 25, 2006 5:00 PM > > To: Stastny Richard; timothy.dwight@verizon.com; Michael Hammer=20 > > (mhammer); timothy.dwight@verizon.com; Brian Rosen; Francois D.=20 > > Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > > Subject: RE: [Speermint] Location Function in SPEERMINT > >=20 > > I believe it is enough. You could refine it but I might sure of the=20 > > benefits. Maybe this problem was already solved somewhere=20 > and I'm not=20 > > aware. > >=20 > > For example, The UAs would care. > >=20 > > >From RFC3263 > >=20 > > ;; Priority Weight Port Target > > IN SRV 0 1 5060 server1.example.com > > IN SRV 0 2 5060 server2.example.com > >=20 > > This tells you the SIP proxy to be contacted. It does not=20 > tell you if=20 > > this the closest Sip Proxy handling @example.com users. It=20 > also does=20 > > not tell you if it is the closest proxy to the callee. > >=20 > > In the case of a carriers providing VoIP service to a user, if this=20 > > provider A peers with provider B in two different=20 > locations, which one=20 > > to choose to send to forward the call? > >=20 > > Regards, > >=20 > > Reinaldo > >=20 > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, May 25, 2006 1:52 PM > > > To: Reinaldo Penno; timothy.dwight@verizon.com; Michael Hammer > > (mhammer); > > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > > Sohel Q > > > [CTO]; David Meyer; speermint@ietf.org > > > Subject: Re: [Speermint] Location Function in SPEERMINT > > >=20 > > > Reinaldo said: > > > >That's maybe one of the most important issues. This could be > > complicated > > > >by the geographically dispersed networks with several=20 > entry points. > > > >Although this might be an interesting problem it might be > > a rathole. > > >=20 > > > So you say RFC 3263 is not enough, something is missing? > > > e.g. the geographic location of originating and terminating > > --- what? > > >=20 > > > -SIP proxy? who cares > > > -SBC? > > > -UA? > > >=20 > > > So we are again dealing with SBCs, in this case the=20 > geo-location of > > these > > > -- rats, holes ;-) > > >=20 > > > Richard > > >=20 > > >=20 > > > ________________________________ > > >=20 > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Gesendet: Do 25.05.2006 22:37 > > > An: Stastny Richard; timothy.dwight@verizon.com; Michael Hammer > > (mhammer); > > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > > Sohel Q > > > [CTO]; David Meyer; speermint@ietf.org > > > Betreff: RE: [Speermint] Location Function in SPEERMINT > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, May 25, 2006 1:26 PM > > > > To: timothy.dwight@verizon.com; Michael Hammer (mhammer);=20 > > > > timothy.dwight@verizon.com; Brian Rosen; Francois D.=20 > Menard; Khan, > > > Sohel Q > > > > [CTO]; David Meyer; speermint@ietf.org > > > > Subject: [Speermint] Location Function in SPEERMINT > > > > > > > > Hi all, > > > > > > > > sorry, but I am only able to reply with a short > > statement, because I > > > am > > > > on vacation and have only limited time and bandwitdh (GPRS) > > > > > > > > First, I consider this discussion regarding Infrastructure ENUM, > > LERG > > > and > > > > LNP > > > > important, but in the wrong WG. It should be discussed=20 > in ENUM. WG > > and > > > > not in SPEERMINT > > > > > > > > SPEERMINT is only dealing with Call Routing Data (CRD), which is > > > defined > > > > as the OUTPUT of ENUM or some other means. > > > > > > > > This implies, that the location function (LF) defined in the=20 > > > > achitecture draft happens AFTER an ENUM query and > > therefore cannot > > > > be the part of the LF. > > > > > > > > The LF can only involve the location of the destination=20 > "network" > > > > as defined in SPEERMINT by the use of CRD (which is > > basically a SIP > > > > URI because we are currently talking only SIP in SPEERMINT) > > > > > > > > Of course SPEERMINT needs to define what it considers > > CRD, and AoR > > > > or the ingress point of a network. > > > > > > > > BUT then SPEERMINT needs also to define how the ingress > > point of a > > > > "network" is LOCATED given a SIP AoR. > > > [[Reinaldo]] > > >=20 > > > That's maybe one of the most important issues. This could be > > complicated > > > by the geographically dispersed networks with several=20 > entry points. > > > Although this might be an interesting problem it might be=20 > a rathole. > > >=20 > > >=20 > > > > > > > > Richard > > > > > > > > > > > > ________________________________ > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > Gesendet: Do 25.05.2006 20:17 > > > > An: 'Michael Hammer (mhammer)'; > > timothy.dwight@verizon.com; Stastny > > > > Richard; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, > > Sohel Q [CTO]'; > > > > 'David Meyer'; speermint@ietf.org > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering=20 > Architecture - LF - > > OF > > > - SF > > > > > > > > > > > > > > > > Michael Hammer said: > > > > > > > > > Tim, > > > > > > > > > > The LERG and LNP databases are intrinsically tied to > > the operation > > > of > > > > the > > > > TDM > > > > > infrastructure. Any design that perpatuates these=20 > systems when > > > their > > > > reason > > > > > for being (TDM) goes away is a faulty design. > > > > > > > > OK with me. I only meant to point out that right now I > > have these > > > > capabilities, so recreating them isn't a high priority. > > > > > > > > > > > > > > > > > > DNS and ENUM provides the equivalent information and > > mechanisms to > > > do > > > > what > > > > is > > > > > needed in the IP domain. As such, a design that makes > > dependencies > > > on > > > > legacy > > > > > systems is deficient. I wouldn't support such a kludge. > > > > > > > > Fine. > > > > > > > > I'm a big fan of IP-domain solutions. Specifically=20 > Infrastructure > > > ENUM > > > > looks really handy; my point before was that it's=20 > moreso when used > > in > > > what > > > > Richard called "option 1". The alternative ("option 2") only > > > replicates > > > > the > > > > "kludge" to which I already have access. > > > > > > > > And to be fair to Richard, he did point out (subtly) that > > the latter > > > claim > > > > is a bit myopic. There are existing means by which=20 > VSPs can gain > > > access > > > > to > > > > number portability information relative to national=20 > destinations. > > > They > > > > don't have such access, at least not easily and not > > universally, to > > > number > > > > portability information relative to international > > destinations. If > > > that > > > > could be provided by Infrastructure ENUM (either "option 1" or > > "option > > > 2") > > > > it would be useful and would not simply replicate existing > > > capabilities. > > > > > > > > Bottom line, both options defined by Richard, would add value. > > Option > > > 1 > > > > adds more value but is specific to destinations > > identified by E.164 > > > > numbers or URIs with imbedded E.164 numbers. Which is > > the problem > > > > closest > > to > > > > hand. > > > > > > > > > > > > > > > > > > That said, if there are backward compatibilities during the > > > transition, > > > > where > > > > > some information just happens to be known by external systems, > > such > > > as > > > > you > > > > suggest > > > > > below, I don't see that as a problem. I am just wary > > of ending up > > > with > > > > two > > > > > systems in the end when one would do. > > > > > > > > Isn't it inevitable that for some time, both will=20 > exist? Just as > > the > > > GSTN > > > > and VoIP will coexist for some time, so will their supporting=20 > > > > infrastructure. > > > > > > > > Don't get me wrong. I'm not saying "because I have an=20 > SS7 -based > > > solution > > > > to LNP I don't need an IP -based solution". All I'm > > saying is that > > > when > > > > given the option of using Infrastructure ENUM to=20 > recreate (and in > > the > > > case > > > > of international destinations, extend) the capability I already > > have, > > > and > > > > using it to do that and more, I'm inclined to prefer the latter. > > > > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > > Sent: Wednesday, May 24, 2006 6:19 PM > > > > > To: 'Stastny Richard'; timothy.dwight@verizon.com;=20 > > > > > timothy.dwight@verizon.com; Michael Hammer (mhammer); 'Brian > > Rosen'; > > > > > 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer';=20 > > > > > speermint@ietf.org > > > > > Subject: RE: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > OF > > > > > - SF > > > > > > > > > > Richard, > > > > > > > > > > Yes I know I was mixing data and mechanism-to-access-data. > > > > > Still I believe the major point to be correct. In=20 > many parts of > > the > > > > > world there are already mechanisms (associated with=20 > Local Number > > > > > Portability) to determine ownership of an E.164 number, > > hence use > > of > > > > > ENUM for this purpose alone, will be unnecessary. > > > > > > > > > > To be clear, I believe that providing access via=20 > Infrastructure > > ENUM > > > > > to LNP information may be very helpful; but only if > > Infrastructure > > > > > ENUM provides more than just this. > > > > > If an Infrastructure ENUM query can combine (a) > > determination of > > > the > > > > > entity providing service to the destination, (b) > > determination of > > > the > > > > > corresponding LRN, if one exists, and (c) mapping of > > the routable > > > > > number (either the number originally indicated, or=20 > the LRN) to a > > > Layer > > > > > 5 "point of ingress" specified by the entity providing > > service to > > > the > > > > > destination; then Infrastructure ENUM is quite a handy > > mechanism. > > > If > > > > > all it does is (a) then I don't need it. > > > > > > > > > > But in the end this is neither here nor there. I am > > not wedded to > > > any > > > > > specific technology, I just need workable solutions to real > > business > > > > > problems. > > > > > > > > > > Tim > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Wednesday, May 24, 2006 4:38 PM > > > > > To: timothy.dwight@verizon.com; timothy.dwight@verizon.com; > > Michael > > > > > Hammer (mhammer); Brian Rosen; Francois D. Menard; > > Khan, Sohel Q > > > > > [CTO]; David Meyer; speermint@ietf.org > > > > > Subject: Re: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > OF > > > > > - SF > > > > > > > > > > Tim, > > > > > > > > > > thanx for your reply, you are raising some important issues. > > > > > Since it is already midnight here, I will reply to it=20 > in detail=20 > > > > > tomorrow > > > > > > > > > > I am also working on a more detailed analysis and a=20 > draft which > > will > > > > > require even some more time. > > > > > > > > > > Just a quick one: > > > > > > > > > > >In some parts of the world the function provided by "option > > > > > 2" usage of > > > > > >Infrastructure ENUM could be achieved in other ways (e.g., > > > > > the LERG and > > > > > >NPDB in North America) so in those cases Infrastructure ENUM > > > > > might be a > > > > > >superfluous concept; but if that's the right technical > > > > > answer so be it. > > > > > > > > > > Yes and no ;-) > > > > > You are mixing up here the Registry and the ENUM DNS. > > > > > The Registry is the LERG and NPDB (or is derived=20 > from), the ENUM > > DNS > > > > > is the equivalent on IP of the SCP in the PSTN where > > the date is > > > > > downloaded to. > > > > > > > > > > Richard > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > > Gesendet: Mi 24.05.2006 23:00 > > > > > An: Stastny Richard; timothy.dwight@verizon.com; > > 'Michael Hammer > > > > > (mhammer)'; 'Brian Rosen'; 'Francois D. Menard';=20 > 'Khan, Sohel Q=20 > > > > > [CTO]'; 'David Meyer'; speermint@ietf.org > > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > OF > > > > > - SF > > > > > > > > > > > > > > > > > > > > Richard, > > > > > > > > > > Thank you for the clarification. I understand the > > distinction you > > > are > > > > > making. > > > > > > > > > > My objective is to be able to translate a destination=20 > identifier > > > > > (E.164 number of alphanumeric AoR) into the address of > > a Layer 5 > > > > > entity designated by the organization providing service to the > > > called > > > > > party. With infrastructure/carrier ENUM I could do this (as > > > described > > > > > in your Option 1), but because ENUM is specific to=20 > E.164 numbers > > it > > > > > would only work for E.164 -formatted destination identifiers. > > > > > > > > > > In pictures, your Option 2 seems to me to imply the following: > > > > > > > > > > +----------------+ +----------+ > > > > > E.164 | infrastructure | serving | identify > > > > > | network > > > > > ingress > > > > > destination -->| ENUM |---> carrier --->| ingress > > > > > |---> point > > > > > specified > > > > > identifier | (option 2) | identity | point | > > > by > > > > > serving carrier > > > > > +----------------+ ^ +----------+ > > > > > | > > > > > +----------------+ | > > > > > non-E.164 | map domain in | | > > > > > Destination -->| URI to carrier |--------+ > > > > > Identifier | identity | > > > > > +----------------+ > > > > > > > > > > In some parts of the world the function provided by "option 2" > > usage > > > > > of Infrastructure ENUM could be achieved in other ways > > (e.g., the > > > LERG > > > > > and NPDB in North America) so in those cases=20 > Infrastructure ENUM > > > might > > > > > be a superfluous concept; but if that's the right > > technical answer > > > so > > > > > be it. > > > > > > > > > > The "identify ingress point" function would need to be > > defined. I > > > > > would like it to consider the specified destination=20 > (in addition > > to > > > > > the carrier providing service to that destination);=20 > and I would > > like > > > > > the procedures to be such that the serving carrier > > controls (in a > > > > > reasonably dynamic > > > > > way) the point at which traffic destined to a particular > > > destination, > > > > > enters his network. If those requirements can be met, I think > > this > > > > > approach is workable. > > > > > > > > > > Its biggest drawback is that it precludes a solution=20 > ("option 1" > > > usage > > > > > of Infrastructure ENUM) that is sufficient for the majority of > > > today's > > > > > needs. > > > > > It optimizes for a problem that will exist in the=20 > future at the=20 > > > > > expense of solving problems that exist today. I realize that > > > solving > > > > > today's problems may not be SPEERMINT's focus, or > > (arguably) even > > > > > within its charter, but I would hate to see > > recommendations from > > > > > SPEERMINT preclude or significantly delay solving them. > > > > > > > > > > Suppose we did something like this: > > > > > > > > > > +----------+ [pseudo +----------------+ > > > > > non-E.164 | identify | or real] | infrastructure > > > > > | network > > > > > ingress > > > > > destination -->| "pseudo" |---> E.164 --->| ENUM > > > > > |---> point > > > > > specified > > > > > identifier | E.164 | number | (option 1) | > > > by > > > > > serving carrier > > > > > +----------+ +----------------+ > > > > > > > > > > We could let the ENUM working group define > > Infrastructure ENUM as > > > > > described in your Option 1 (which is as you know already > > > commercially > > > > > available from a few sources) and SPEERMINT could define the > > > "identify > > > > > pseudo E.164" function that in my diagram feeds into=20 > it. This=20 > > > > > function might be as simple as mapping the domain part > > of the URI > > to > > > > > an E.164 number uniquely associated with the network providing > > > service > > > > > to the specified destination. Unless this is a lot > > harder than it > > > > > seems, this shouldn't keep us busy too long :-) > > > > > > > > > > > > > > > Tim > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Wednesday, May 24, 2006 11:16 AM > > > > > To: timothy.dwight@verizon.com; Michael Hammer=20 > (mhammer); Brian=20 > > > > > Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer;=20 > > > > > speermint@ietf.org > > > > > Subject: Re: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > > > OF - SF > > > > > > > > > > Tim, > > > > > > > > > > >> ... the basic idea of Infrastructure ENUM (which=20 > will be used > > for > > > > > >> service providers is to provide a domain name in a > > SIP URI =3D a > > > > > >> service provider ID > > > > > >(SPID) > > > > > > > > > > >At the risk of asking an off-topic question (realizing that > > > > > ENUM is not > > > > > >within scope for SPEERMINT), can I ask where the idea that=20 > > > > > >Infrastructure ENUM queries return SPIDs, comes from? It is > > > > > my intent > > > > > >to provide a point of interconnection to be used by the > > requesting > > > > > >entity to hand to me a call to the specified number. I do > > > > > not intend > > > > > >that the only meaningful part of the URI returned from the > > > > > ENUM query, > > > > > >be > > > > > the domain name. > > > > > > > > > > thank you for raising this important point. I tried to > > raise this > > > > > some time ago, but got no clear answer > > > > > > > > > > Currently there exist two lines of thought about the usage of=20 > > > > > Infrastructure (and also Carrier ENUM in private trees) > > > > > > > > > > 1. Put in ENUM the ingress point(s) e.g. > > > > > sip:+43xxxx@sbc4711.provider.net 2. > > > > > Put in ENUM the AoR only: e.g. sip:+43xxx@provider.net=20 > > > > > (provider.net is what I meant with SPID) > > > > > > > > > > Most currently prefer option 1, especially in private > > ENUM trees. > > > > > > > > > > IMHO this is the wrong approach: > > > > > > > > > > There should be a clear separation (and it is in the charter)=20 > > > > > between ENUM and SPEERMINT SPEERMINT peering MUST be > > able to work > > > > > standalone and without ENUM. > > > > > > > > > > Option 1 assumes also that the user is entering ALWAYS an > > > > > E.164 number as identifier. > > > > > > > > > > But what if he is entering an AoR? > > > > > > > > > > SPEEMINT peering MUST be able to resolve this too so > > you need to > > > > > find the ingress point independant of ENUM e.g. via RFC3263. > > > > > > > > > > If this MUST be possible, why not enter in (any) ENUM=20 > just the=20 > > > > > AoR, if you must be able to resolve the AoR anyway? > > > > > > > > > > Otherwise you need to manage two mappings separate 1. the > > > > > E.164 to ingress point 2. the AoR mapping to ingress point > > > > > > > > > > this is not a good idea > > > > > > > > > > This is the reason why I would prefer to enter in ENUM > > AoRs only > > > > > the user part in ENUM is always the E.164 number (for privacy > > > > > reasons) the domain part is the SPID, which is mapped=20 > later to=20 > > > > > find the ingress point > > > > > > > > > > the calling user may then also use an alis AoR such as=20 > > > > > sip:name@provider.net > > > > > > > > > > regards > > > > > > > > > > Richard > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > > Gesendet: Mi 24.05.2006 16:46 > > > > > An: Stastny Richard; 'Michael Hammer (mhammer)';=20 > 'Brian Rosen';=20 > > > > > 'Francois D. > > > > > Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; > > speermint@ietf.org > > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > > > OF - SF > > > > > > > > > > > > > > > > > > > > Stastny, Richard said: > > > > > > > > > > > ... the basic idea of Infrastructure ENUM (which=20 > will be used > > for > > > > > > service providers is to provide a domain name in a SIP URI > > > > > =3D a service > > > > > > provider ID > > > > > (SPID) > > > > > > > > > > At the risk of asking an off-topic question (realizing > > that ENUM > > > > > is not within scope for SPEERMINT), can I ask where the > > idea that > > > > > Infrastructure ENUM queries return SPIDs, comes from?=20 > It is my=20 > > > > > intent to provide a point of interconnection to be=20 > used by the=20 > > > > > requesting entity to hand to me a call to the specified > > number. I > > > > > do not intend that the only meaningful part of the=20 > URI returned=20 > > > > > from the ENUM query, be the domain name. > > > > > > > > > > tim > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 12:48:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjfUa-0000J0-Kq; Fri, 26 May 2006 12:48:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjfUa-0000Iv-2q for speermint@ietf.org; Fri, 26 May 2006 12:48:52 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjfUY-0007qi-Ph for speermint@ietf.org; Fri, 26 May 2006 12:48:52 -0400 Received: from PMelampy [10.0.200.157] by acmepacket.com with ESMTP (SMTPD-9.03) id A1690384; Fri, 26 May 2006 12:48:41 -0400 From: "Patrick Melampy" To: "'Otmar Lendl'" Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Fri, 26 May 2006 12:48:41 -0400 Message-ID: <03b101c680e4$3e963cd0$0202fea9@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaAyUyv8ZiW0Tq0QsyFoiRh/84djAAGORqA In-Reply-To: <20060526133546.GB27495@nic.at> X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: "'Khan, Sohel Q \[CTO\]'" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I suppose like in any distributed routing protocol, there are some chicken an egg issues. But consider the following. PREREQUISITES: 1.) You know the destination DOMAIN from either ENUM or other means. Consider 3 carriers A, B, C A subscribes to B for a list of reachable domains. B notifies A that both B and C are reachable. B subscribes to A for a list of reachable domains. A notifies B that A is reachable C subscribes to B for a list of reachable domains. B notifies C that both A and B are reachable. B subscribes to C for a list of reachable domains. C notifies B that C is reachable. Now domain A can send SIP based communications for destinations in B or C domains. Likewise, C can send SIP based communications for destinations in A or B. If C were to become unreachable -- B would notify A. This technique is very similar to TRIP, only its for DOMAINS and not partial E.164 numbers. These SUBSCRIBE/NOTIFY sequences could occur between adjacent proxies -- proxies that are dedicated edge proxies for routing between these carriers. The actual policies in force could be different at each and every adjacent proxy location. Obviously, the data set could get large, as the list of domains can be really big. There are some possibilities here... 1.) Have notification point to a published document, and the document lists all of the relevant reachability in real time. Thus any change to the document would generate a NOTIFICATION. 2.) User partial domains, broken up by the "dots". This may allow some wildcarding to reduce the number of domains. For instance, a carrier like Verizon may have many 100's of domains attached to it, and version is willing to route and manage SIP traffic to any of them. The NOTIFY could contain something like: Verizon.com or *.verizon.com to indicate that any domain in Verizon is reachable. An issue does arise when thinking about PSTN numbers. Since many carriers will have an interface to the PSTN, these are not owned by any domain. Thus we may need to expand support for PSTN reachable numbers somehow? One idea would be to also perform subscribe and notify for partial E.164 numbers similar to how it was proposed in the TRIP protocol. This technique may work -- and fit nicely into an existing protocol. All we would need to do is define the data models (XML?) and or documents for exchanging. -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at] Sent: Friday, May 26, 2006 9:36 AM To: Patrick Melampy Cc: 'Michael Hammer (mhammer)'; 'Khan, Sohel Q [CTO]'; speermint@ietf.org Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture On 2006/05/24 17:05, Patrick Melampy wrote: > Subscriptions have other beneficial attributes -- as they can work across > network boundaries and have context. Subscribe/Notify can deliver a policy > that corresponds to a reverse flow of SIP traffic. Plus the Notification can > provide near real time changes. Also very contextual data can be included in > the notification -- providing a nice mechanism for automatic congestion > control. > > I like DNS providing LOCATION only, and I like the notion of all other > attributes that have a contextual base to be delivered in a contextual way. I think I can see your point. I still have a serious problem regarding how to bootstrap such a system as * Carriers seem to hate to expose their SIP ingress elements to the open Internet. They firewall, use private address spaces (e.g. GRX) or otherwise block incoming SIP calls before they reach the SIP stack. * we want to avoid a mandatory bilateral configuration of peerings. Could you sketch how a dynamic peering discovery could work with a SIP subscription model? /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 12:49:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjfV8-0000LV-Sm; Fri, 26 May 2006 12:49:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjfV7-0000LM-T8 for speermint@ietf.org; Fri, 26 May 2006 12:49:25 -0400 Received: from [204.209.140.176] (helo=wodka.aus-biz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjfV6-0007w9-Fx for speermint@ietf.org; Fri, 26 May 2006 12:49:25 -0400 Received: from [192.168.1.103] (cpe-24-95-54-117.columbus.res.rr.com [24.95.54.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Duane Groth", Issuer "CAcert Class 3 Root" (not verified)) by wodka.aus-biz.com (Postfix) with ESMTP id 894FA3CBF; Fri, 26 May 2006 12:49:21 -0400 (EDT) Message-ID: <4477318E.2050305@e164.org> Date: Fri, 26 May 2006 12:49:18 -0400 From: Duane User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture References: <072C5B76F7CEAB488172C6F64B30B5E3018480F1@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3018480F1@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Stastny Richard , speermint@ietf.org, Otmar Lendl , "Khan, Sohel Q \[CTO\]" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Michael Hammer (mhammer) wrote: > Duane, > > Your argument depends on the assertion that it is only 20 more bytes of > data. I don't think we are at a point yet to be able to conclude that > conclusively. There may be a range of data from very simply to more > complex. We need to work through this. When I said 20 bytes I was being facetious, it could be 2000 bytes or 5M for all it really matters because at the end of the day DNS for the most part is pulled not pushed so the user only asks for what they need and only gets what they asked for. The problem most have with the idea of a directory service rather then some kind of replication of the PSTN network is tradition telco type guys are used to collecting interconnect fees and so they want to come up with some other way so they can still perform settlements. It's possible to keep operating in this manner, although it's going to need a BGP style system (or least cost rather then shortest path, or perhaps a mixing of the two) and some kind of clearing house to facilitate settlements between carriers. -- Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://e164.org - Because e164.arpa is a tax on VoIP "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 12:51:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjfX4-0000V4-0M; Fri, 26 May 2006 12:51:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjfX2-0000Uq-GJ for speermint@ietf.org; Fri, 26 May 2006 12:51:24 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FjfWy-0008Ih-J3 for speermint@ietf.org; Fri, 26 May 2006 12:51:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Location Function in SPEERMINT Date: Fri, 26 May 2006 18:55:22 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A7B@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Location Function in SPEERMINT Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAATumxgAG4BNwABEZoVAADQ2DIAAC1z/9AAGrFeAACZ2pfQABju7wACHfcEAAAbB9IAAK1HH6AAC9BtAAAGOAdAAAMvVgACTEanAAAMf18AAA1j4AAAEyrIAAAVK4MAAAud3b From: "Stastny Richard" To: "James McEachern" , "Michael Hammer \(mhammer\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 28c4c369715777944de1d586eee1c7cb Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org >Possible SPEERMINT requirement: The ability to selectively discover a = specific instance of a proxy/interconnect point for peering. The = criteria used to >select the appropriate proxy include: (here I think = we need to make a specific decision for each potential criterion.) >- peer identity or affiliation (federation) >- location (or distance, or some other suitable related attribute) >- other??? Good start, I lost track myself already ;-) May I try my summary: the Location function is a process containing = eventually more then one step: If you start with the CRD (e.g a SIP AoR entered by the User or = derivered from ENUM) 1. The AoR gives you the destnation network 2. You need to locate the peering club (=3D federation) for exchanging = SIP messages (L5 )with the destination network 3. so you need to locate the policy you want to use and make a decision = on the federation (note: a destination network may belong to more then one federations) 4. having chosen a federation, you need to locate the ingess proxy(ies) = the destination network is using within this federation. 5. If you are using a separate peering for exchanging media, you now may = locate these Richard ________________________________ Von: James McEachern [mailto:jmce@nortel.com] Gesendet: Fr 26.05.2006 18:34 An: Michael Hammer (mhammer); speermint@ietf.org Betreff: RE: [Speermint] Location Function in SPEERMINT Fair enough - I think I may be losing track of "it" myself. Let me take = a stab at it, and then perhaps we can agree if "it" is a requirement or = not. Possible SPEERMINT requirement: The ability to selectively discover a = specific instance of a proxy/interconnect point for peering. The = criteria used to select the appropriate proxy include: (here I think we = need to make a specific decision for each potential criterion.) - peer identity or affiliation (federation) - location (or distance, or some other suitable related attribute) - other??? Jim -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Friday, May 26, 2006 11:51 AM To: McEachern, James [CAR:5N00:EXCH]; speermint@ietf.org Subject: RE: [Speermint] Location Function in SPEERMINT I think I have lost track of what "it" is. I don't think "it" is the ability to identify a proxy that a peer should use based on location. "It" may be the ability to identify a proxy that a peer should use based on the peer identity or affiliation (federation). "Location" has geographic baggage when perhaps selective "discovery" is really what is meant. Please correct me as I may have gotten disoriented with the different mail threads. Mike > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com] > Sent: Friday, May 26, 2006 11:16 AM > To: Michael Hammer (mhammer); speermint@ietf.org > Subject: RE: [Speermint] Location Function in SPEERMINT > > So are you saying that it should be a requirement? > > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, May 26, 2006 10:52 AM > To: McEachern, James [CAR:5N00:EXCH]; Reinaldo Penno; Stastny > Richard; timothy.dwight@verizon.com; > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; > Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > Subject: RE: [Speermint] Location Function in SPEERMINT > > Distance is dead IF the proxy does not have strong ties to a > media anchor point. If there is such a media anchor point, > then choosing ones that are close to calling and called > parties will aid in finding shortest routes between parties. > > However, I am not advocating for or against such media > anchors, just simply recognizing that they may exist > depending on a domain's architecture. > > There may be other reasons that peers are directed to one > proxy over another. It is useful for the domain to designate > which proxies peers should use. > > Mike > > > > -----Original Message----- > > From: James McEachern [mailto:jmce@nortel.com] > > Sent: Friday, May 26, 2006 10:44 AM > > To: Reinaldo Penno; Stastny Richard; > > timothy.dwight@verizon.com; Michael Hammer (mhammer); > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > > Sohel Q [CTO]; David Meyer; speermint@ietf.org > > Subject: RE: [Speermint] Location Function in SPEERMINT > > > > >This tells you the SIP proxy to be contacted. It does not > > tell you if > > >this the closest Sip Proxy handling @example.com users. It > also does > > >not tell you if it is the closest proxy to the callee. > > > > Is the ability to "identify the closest proxy" a requirement for > > Speermint? Many people have pointed out that distance is > dead, or at > > least should be, so it isn't clear to me that we really care. The > > Requirements and Terminology draft doesn't explicitly say, but my > > reading of section 5.2 implies this is not a requirement. > > > > That having been said, I don't necessarily have strong views either > > way. I'd just like to be clear on whether or not it is a > requirement. > > > > Jim > > > > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Thursday, May 25, 2006 5:00 PM > > To: Stastny Richard; timothy.dwight@verizon.com; Michael Hammer > > (mhammer); timothy.dwight@verizon.com; Brian Rosen; Francois D. > > Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > > Subject: RE: [Speermint] Location Function in SPEERMINT > > > > I believe it is enough. You could refine it but I might sure of the > > benefits. Maybe this problem was already solved somewhere > and I'm not > > aware. > > > > For example, The UAs would care. > > > > >From RFC3263 > > > > ;; Priority Weight Port Target > > IN SRV 0 1 5060 server1.example.com > > IN SRV 0 2 5060 server2.example.com > > > > This tells you the SIP proxy to be contacted. It does not > tell you if > > this the closest Sip Proxy handling @example.com users. It > also does > > not tell you if it is the closest proxy to the callee. > > > > In the case of a carriers providing VoIP service to a user, if this > > provider A peers with provider B in two different > locations, which one > > to choose to send to forward the call? > > > > Regards, > > > > Reinaldo > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, May 25, 2006 1:52 PM > > > To: Reinaldo Penno; timothy.dwight@verizon.com; Michael Hammer > > (mhammer); > > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > > Sohel Q > > > [CTO]; David Meyer; speermint@ietf.org > > > Subject: Re: [Speermint] Location Function in SPEERMINT > > > > > > Reinaldo said: > > > >That's maybe one of the most important issues. This could be > > complicated > > > >by the geographically dispersed networks with several > entry points. > > > >Although this might be an interesting problem it might be > > a rathole. > > > > > > So you say RFC 3263 is not enough, something is missing? > > > e.g. the geographic location of originating and terminating > > --- what? > > > > > > -SIP proxy? who cares > > > -SBC? > > > -UA? > > > > > > So we are again dealing with SBCs, in this case the > geo-location of > > these > > > -- rats, holes ;-) > > > > > > Richard > > > > > > > > > ________________________________ > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Gesendet: Do 25.05.2006 22:37 > > > An: Stastny Richard; timothy.dwight@verizon.com; Michael Hammer > > (mhammer); > > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > > Sohel Q > > > [CTO]; David Meyer; speermint@ietf.org > > > Betreff: RE: [Speermint] Location Function in SPEERMINT > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, May 25, 2006 1:26 PM > > > > To: timothy.dwight@verizon.com; Michael Hammer (mhammer); > > > > timothy.dwight@verizon.com; Brian Rosen; Francois D. > Menard; Khan, > > > Sohel Q > > > > [CTO]; David Meyer; speermint@ietf.org > > > > Subject: [Speermint] Location Function in SPEERMINT > > > > > > > > Hi all, > > > > > > > > sorry, but I am only able to reply with a short > > statement, because I > > > am > > > > on vacation and have only limited time and bandwitdh (GPRS) > > > > > > > > First, I consider this discussion regarding Infrastructure ENUM, > > LERG > > > and > > > > LNP > > > > important, but in the wrong WG. It should be discussed > in ENUM. WG > > and > > > > not in SPEERMINT > > > > > > > > SPEERMINT is only dealing with Call Routing Data (CRD), which is > > > defined > > > > as the OUTPUT of ENUM or some other means. > > > > > > > > This implies, that the location function (LF) defined in the > > > > achitecture draft happens AFTER an ENUM query and > > therefore cannot > > > > be the part of the LF. > > > > > > > > The LF can only involve the location of the destination > "network" > > > > as defined in SPEERMINT by the use of CRD (which is > > basically a SIP > > > > URI because we are currently talking only SIP in SPEERMINT) > > > > > > > > Of course SPEERMINT needs to define what it considers > > CRD, and AoR > > > > or the ingress point of a network. > > > > > > > > BUT then SPEERMINT needs also to define how the ingress > > point of a > > > > "network" is LOCATED given a SIP AoR. > > > [[Reinaldo]] > > > > > > That's maybe one of the most important issues. This could be > > complicated > > > by the geographically dispersed networks with several > entry points. > > > Although this might be an interesting problem it might be > a rathole. > > > > > > > > > > > > > > Richard > > > > > > > > > > > > ________________________________ > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > Gesendet: Do 25.05.2006 20:17 > > > > An: 'Michael Hammer (mhammer)'; > > timothy.dwight@verizon.com; Stastny > > > > Richard; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, > > Sohel Q [CTO]'; > > > > 'David Meyer'; speermint@ietf.org > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering > Architecture - LF - > > OF > > > - SF > > > > > > > > > > > > > > > > Michael Hammer said: > > > > > > > > > Tim, > > > > > > > > > > The LERG and LNP databases are intrinsically tied to > > the operation > > > of > > > > the > > > > TDM > > > > > infrastructure. Any design that perpatuates these > systems when > > > their > > > > reason > > > > > for being (TDM) goes away is a faulty design. > > > > > > > > OK with me. I only meant to point out that right now I > > have these > > > > capabilities, so recreating them isn't a high priority. > > > > > > > > > > > > > > > > > > DNS and ENUM provides the equivalent information and > > mechanisms to > > > do > > > > what > > > > is > > > > > needed in the IP domain. As such, a design that makes > > dependencies > > > on > > > > legacy > > > > > systems is deficient. I wouldn't support such a kludge. > > > > > > > > Fine. > > > > > > > > I'm a big fan of IP-domain solutions. Specifically > Infrastructure > > > ENUM > > > > looks really handy; my point before was that it's > moreso when used > > in > > > what > > > > Richard called "option 1". The alternative ("option 2") only > > > replicates > > > > the > > > > "kludge" to which I already have access. > > > > > > > > And to be fair to Richard, he did point out (subtly) that > > the latter > > > claim > > > > is a bit myopic. There are existing means by which > VSPs can gain > > > access > > > > to > > > > number portability information relative to national > destinations. > > > They > > > > don't have such access, at least not easily and not > > universally, to > > > number > > > > portability information relative to international > > destinations. If > > > that > > > > could be provided by Infrastructure ENUM (either "option 1" or > > "option > > > 2") > > > > it would be useful and would not simply replicate existing > > > capabilities. > > > > > > > > Bottom line, both options defined by Richard, would add value. > > Option > > > 1 > > > > adds more value but is specific to destinations > > identified by E.164 > > > > numbers or URIs with imbedded E.164 numbers. Which is > > the problem > > > > closest > > to > > > > hand. > > > > > > > > > > > > > > > > > > That said, if there are backward compatibilities during the > > > transition, > > > > where > > > > > some information just happens to be known by external systems, > > such > > > as > > > > you > > > > suggest > > > > > below, I don't see that as a problem. I am just wary > > of ending up > > > with > > > > two > > > > > systems in the end when one would do. > > > > > > > > Isn't it inevitable that for some time, both will > exist? Just as > > the > > > GSTN > > > > and VoIP will coexist for some time, so will their supporting > > > > infrastructure. > > > > > > > > Don't get me wrong. I'm not saying "because I have an > SS7 -based > > > solution > > > > to LNP I don't need an IP -based solution". All I'm > > saying is that > > > when > > > > given the option of using Infrastructure ENUM to > recreate (and in > > the > > > case > > > > of international destinations, extend) the capability I already > > have, > > > and > > > > using it to do that and more, I'm inclined to prefer the latter. > > > > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > > Sent: Wednesday, May 24, 2006 6:19 PM > > > > > To: 'Stastny Richard'; timothy.dwight@verizon.com; > > > > > timothy.dwight@verizon.com; Michael Hammer (mhammer); 'Brian > > Rosen'; > > > > > 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; > > > > > speermint@ietf.org > > > > > Subject: RE: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > OF > > > > > - SF > > > > > > > > > > Richard, > > > > > > > > > > Yes I know I was mixing data and mechanism-to-access-data. > > > > > Still I believe the major point to be correct. In > many parts of > > the > > > > > world there are already mechanisms (associated with > Local Number > > > > > Portability) to determine ownership of an E.164 number, > > hence use > > of > > > > > ENUM for this purpose alone, will be unnecessary. > > > > > > > > > > To be clear, I believe that providing access via > Infrastructure > > ENUM > > > > > to LNP information may be very helpful; but only if > > Infrastructure > > > > > ENUM provides more than just this. > > > > > If an Infrastructure ENUM query can combine (a) > > determination of > > > the > > > > > entity providing service to the destination, (b) > > determination of > > > the > > > > > corresponding LRN, if one exists, and (c) mapping of > > the routable > > > > > number (either the number originally indicated, or > the LRN) to a > > > Layer > > > > > 5 "point of ingress" specified by the entity providing > > service to > > > the > > > > > destination; then Infrastructure ENUM is quite a handy > > mechanism. > > > If > > > > > all it does is (a) then I don't need it. > > > > > > > > > > But in the end this is neither here nor there. I am > > not wedded to > > > any > > > > > specific technology, I just need workable solutions to real > > business > > > > > problems. > > > > > > > > > > Tim > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Wednesday, May 24, 2006 4:38 PM > > > > > To: timothy.dwight@verizon.com; timothy.dwight@verizon.com; > > Michael > > > > > Hammer (mhammer); Brian Rosen; Francois D. Menard; > > Khan, Sohel Q > > > > > [CTO]; David Meyer; speermint@ietf.org > > > > > Subject: Re: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > OF > > > > > - SF > > > > > > > > > > Tim, > > > > > > > > > > thanx for your reply, you are raising some important issues. > > > > > Since it is already midnight here, I will reply to it > in detail > > > > > tomorrow > > > > > > > > > > I am also working on a more detailed analysis and a > draft which > > will > > > > > require even some more time. > > > > > > > > > > Just a quick one: > > > > > > > > > > >In some parts of the world the function provided by "option > > > > > 2" usage of > > > > > >Infrastructure ENUM could be achieved in other ways (e.g., > > > > > the LERG and > > > > > >NPDB in North America) so in those cases Infrastructure ENUM > > > > > might be a > > > > > >superfluous concept; but if that's the right technical > > > > > answer so be it. > > > > > > > > > > Yes and no ;-) > > > > > You are mixing up here the Registry and the ENUM DNS. > > > > > The Registry is the LERG and NPDB (or is derived > from), the ENUM > > DNS > > > > > is the equivalent on IP of the SCP in the PSTN where > > the date is > > > > > downloaded to. > > > > > > > > > > Richard > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > > Gesendet: Mi 24.05.2006 23:00 > > > > > An: Stastny Richard; timothy.dwight@verizon.com; > > 'Michael Hammer > > > > > (mhammer)'; 'Brian Rosen'; 'Francois D. Menard'; > 'Khan, Sohel Q > > > > > [CTO]'; 'David Meyer'; speermint@ietf.org > > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > OF > > > > > - SF > > > > > > > > > > > > > > > > > > > > Richard, > > > > > > > > > > Thank you for the clarification. I understand the > > distinction you > > > are > > > > > making. > > > > > > > > > > My objective is to be able to translate a destination > identifier > > > > > (E.164 number of alphanumeric AoR) into the address of > > a Layer 5 > > > > > entity designated by the organization providing service to the > > > called > > > > > party. With infrastructure/carrier ENUM I could do this (as > > > described > > > > > in your Option 1), but because ENUM is specific to > E.164 numbers > > it > > > > > would only work for E.164 -formatted destination identifiers. > > > > > > > > > > In pictures, your Option 2 seems to me to imply the following: > > > > > > > > > > +----------------+ +----------+ > > > > > E.164 | infrastructure | serving | identify > > > > > | network > > > > > ingress > > > > > destination -->| ENUM |---> carrier --->| ingress > > > > > |---> point > > > > > specified > > > > > identifier | (option 2) | identity | point | > > > by > > > > > serving carrier > > > > > +----------------+ ^ +----------+ > > > > > | > > > > > +----------------+ | > > > > > non-E.164 | map domain in | | > > > > > Destination -->| URI to carrier |--------+ > > > > > Identifier | identity | > > > > > +----------------+ > > > > > > > > > > In some parts of the world the function provided by "option 2" > > usage > > > > > of Infrastructure ENUM could be achieved in other ways > > (e.g., the > > > LERG > > > > > and NPDB in North America) so in those cases > Infrastructure ENUM > > > might > > > > > be a superfluous concept; but if that's the right > > technical answer > > > so > > > > > be it. > > > > > > > > > > The "identify ingress point" function would need to be > > defined. I > > > > > would like it to consider the specified destination > (in addition > > to > > > > > the carrier providing service to that destination); > and I would > > like > > > > > the procedures to be such that the serving carrier > > controls (in a > > > > > reasonably dynamic > > > > > way) the point at which traffic destined to a particular > > > destination, > > > > > enters his network. If those requirements can be met, I think > > this > > > > > approach is workable. > > > > > > > > > > Its biggest drawback is that it precludes a solution > ("option 1" > > > usage > > > > > of Infrastructure ENUM) that is sufficient for the majority of > > > today's > > > > > needs. > > > > > It optimizes for a problem that will exist in the > future at the > > > > > expense of solving problems that exist today. I realize that > > > solving > > > > > today's problems may not be SPEERMINT's focus, or > > (arguably) even > > > > > within its charter, but I would hate to see > > recommendations from > > > > > SPEERMINT preclude or significantly delay solving them. > > > > > > > > > > Suppose we did something like this: > > > > > > > > > > +----------+ [pseudo +----------------+ > > > > > non-E.164 | identify | or real] | infrastructure > > > > > | network > > > > > ingress > > > > > destination -->| "pseudo" |---> E.164 --->| ENUM > > > > > |---> point > > > > > specified > > > > > identifier | E.164 | number | (option 1) | > > > by > > > > > serving carrier > > > > > +----------+ +----------------+ > > > > > > > > > > We could let the ENUM working group define > > Infrastructure ENUM as > > > > > described in your Option 1 (which is as you know already > > > commercially > > > > > available from a few sources) and SPEERMINT could define the > > > "identify > > > > > pseudo E.164" function that in my diagram feeds into > it. This > > > > > function might be as simple as mapping the domain part > > of the URI > > to > > > > > an E.164 number uniquely associated with the network providing > > > service > > > > > to the specified destination. Unless this is a lot > > harder than it > > > > > seems, this shouldn't keep us busy too long :-) > > > > > > > > > > > > > > > Tim > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Wednesday, May 24, 2006 11:16 AM > > > > > To: timothy.dwight@verizon.com; Michael Hammer > (mhammer); Brian > > > > > Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer; > > > > > speermint@ietf.org > > > > > Subject: Re: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > > > OF - SF > > > > > > > > > > Tim, > > > > > > > > > > >> ... the basic idea of Infrastructure ENUM (which > will be used > > for > > > > > >> service providers is to provide a domain name in a > > SIP URI =3D a > > > > > >> service provider ID > > > > > >(SPID) > > > > > > > > > > >At the risk of asking an off-topic question (realizing that > > > > > ENUM is not > > > > > >within scope for SPEERMINT), can I ask where the idea that > > > > > >Infrastructure ENUM queries return SPIDs, comes from? It is > > > > > my intent > > > > > >to provide a point of interconnection to be used by the > > requesting > > > > > >entity to hand to me a call to the specified number. I do > > > > > not intend > > > > > >that the only meaningful part of the URI returned from the > > > > > ENUM query, > > > > > >be > > > > > the domain name. > > > > > > > > > > thank you for raising this important point. I tried to > > raise this > > > > > some time ago, but got no clear answer > > > > > > > > > > Currently there exist two lines of thought about the usage of > > > > > Infrastructure (and also Carrier ENUM in private trees) > > > > > > > > > > 1. Put in ENUM the ingress point(s) e.g. > > > > > sip:+43xxxx@sbc4711.provider.net 2. > > > > > Put in ENUM the AoR only: e.g. sip:+43xxx@provider.net > > > > > (provider.net is what I meant with SPID) > > > > > > > > > > Most currently prefer option 1, especially in private > > ENUM trees. > > > > > > > > > > IMHO this is the wrong approach: > > > > > > > > > > There should be a clear separation (and it is in the charter) > > > > > between ENUM and SPEERMINT SPEERMINT peering MUST be > > able to work > > > > > standalone and without ENUM. > > > > > > > > > > Option 1 assumes also that the user is entering ALWAYS an > > > > > E.164 number as identifier. > > > > > > > > > > But what if he is entering an AoR? > > > > > > > > > > SPEEMINT peering MUST be able to resolve this too so > > you need to > > > > > find the ingress point independant of ENUM e.g. via RFC3263. > > > > > > > > > > If this MUST be possible, why not enter in (any) ENUM > just the > > > > > AoR, if you must be able to resolve the AoR anyway? > > > > > > > > > > Otherwise you need to manage two mappings separate 1. the > > > > > E.164 to ingress point 2. the AoR mapping to ingress point > > > > > > > > > > this is not a good idea > > > > > > > > > > This is the reason why I would prefer to enter in ENUM > > AoRs only > > > > > the user part in ENUM is always the E.164 number (for privacy > > > > > reasons) the domain part is the SPID, which is mapped > later to > > > > > find the ingress point > > > > > > > > > > the calling user may then also use an alis AoR such as > > > > > sip:name@provider.net > > > > > > > > > > regards > > > > > > > > > > Richard > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > > Gesendet: Mi 24.05.2006 16:46 > > > > > An: Stastny Richard; 'Michael Hammer (mhammer)'; > 'Brian Rosen'; > > > > > 'Francois D. > > > > > Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; > > speermint@ietf.org > > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > > > OF - SF > > > > > > > > > > > > > > > > > > > > Stastny, Richard said: > > > > > > > > > > > ... the basic idea of Infrastructure ENUM (which > will be used > > for > > > > > > service providers is to provide a domain name in a SIP URI > > > > > =3D a service > > > > > > provider ID > > > > > (SPID) > > > > > > > > > > At the risk of asking an off-topic question (realizing > > that ENUM > > > > > is not within scope for SPEERMINT), can I ask where the > > idea that > > > > > Infrastructure ENUM queries return SPIDs, comes from? > It is my > > > > > intent to provide a point of interconnection to be > used by the > > > > > requesting entity to hand to me a call to the specified > > number. I > > > > > do not intend that the only meaningful part of the > URI returned > > > > > from the ENUM query, be the domain name. > > > > > > > > > > tim > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 14:07:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjgit-0006RW-Sb; Fri, 26 May 2006 14:07:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjgis-0006RR-Dx for speermint@ietf.org; Fri, 26 May 2006 14:07:42 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjgip-0001Sc-A7 for speermint@ietf.org; Fri, 26 May 2006 14:07:42 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Fjgie-00038W-7c; Fri, 26 May 2006 13:07:29 -0500 From: "Brian Rosen" To: "'Patrick Melampy'" , "'Michael Hammer \(mhammer\)'" , "'James McEachern'" , Subject: RE: [Speermint] Location Function in SPEERMINT Date: Fri, 26 May 2006 14:07:29 -0400 Message-ID: <01ad01c680ef$43a00f20$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <03a301c680e0$a77bb5d0$0202fea9@acmepacket.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAATumxgAG4BNwABEZoVAADQ2DIAAC1z/9AAGrFeAACZ2pfQABju7wACHfcEAAAbB9IAAK1HH6AAC9BtAAAGOAdAAAMvVgACTEanAAAMf18AAA1j4AAAEyrIAAAQ+GAAADlElA X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: c2cee0b4b5285628fa62777413f87ede Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I think the question we want to ask in SPEERMINT is: do we care about any of this? It seems to me that the originating network, and the terminating network, will arrange their signaling through designated peering points. They can, if they want, designate media peering points by using SBCs or other mechanisms that effectively rewrite the SIP message bodies. I think that we can ignore that at the peering point, because when the call gets to the peering point, it's going to have the SDP offer in the INVITE; the media anchor has been decided. Now, in many cases, I expect that as part of its network, the originating network is going to do some kind of lookup (ENUM) that will tell it the destination network, and that could influence its choice of media anchor if it's doing things like that. The point is that I don't think SPEERMINT standardizes that behavior; it's a single element (some SIP proxy) making an internal decision, and routing the call within its network appropriately. Similarly, when the terminating network gets the call, it can make an internal decision to direct the media to some box in its network, which will show up in the answer SDP. Again, that is it's proxy making an internal routing decision. BETWEEN networks, which where we are working, I don't think we are doing any media routing beyond the normal SIP and IP packet stuff. Do I have that right? -----Original Message----- From: Patrick Melampy [mailto:PMelampy@acmepacket.com] Sent: Friday, May 26, 2006 12:23 PM To: 'Michael Hammer (mhammer)'; 'James McEachern'; speermint@ietf.org Subject: RE: [Speermint] Location Function in SPEERMINT One of the best arguments for the "composed" SBC is that if your going to need to locate the "closest media anchor", what better way than associating it with a proxy. If the requirement is to NOT manage the media, but rather let natural BGP4 style internetworking mechanisms route the media optimally, then there is no need to bother with identifying a location of a media anchor. So the real issue here in terms of requirements is: Will Carriers be able to use the autonomous system path (AS_PATH) for delivery and routing of media packets from all sources (customers and suppliers) to all sources (customers and suppliers.) Another way to say the same thing more simply, will carriers put all of the signaled media onto the public internet -- as it's the only internetwork available today. If the answer is NO, then there will need to be media anchors and NAT devices. The location of these devices will be important to the efficiency and manageability of the service offering. The signaling and routing components of the SIP network MUST be aware of the media path, as the signaling plane is establishing the media path. This awareness and state suggest that there needs to be a relationship between the signaling plane and media anchor that is understood and close. I'm going to suggest here that the location of the proxy (the nearest proxy) be a substitute for the nearest media anchor point. -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Friday, May 26, 2006 11:51 AM To: James McEachern; speermint@ietf.org Subject: RE: [Speermint] Location Function in SPEERMINT I think I have lost track of what "it" is. I don't think "it" is the ability to identify a proxy that a peer should use based on location. "It" may be the ability to identify a proxy that a peer should use based on the peer identity or affiliation (federation). "Location" has geographic baggage when perhaps selective "discovery" is really what is meant. Please correct me as I may have gotten disoriented with the different mail threads. Mike > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com] > Sent: Friday, May 26, 2006 11:16 AM > To: Michael Hammer (mhammer); speermint@ietf.org > Subject: RE: [Speermint] Location Function in SPEERMINT > > So are you saying that it should be a requirement? > > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, May 26, 2006 10:52 AM > To: McEachern, James [CAR:5N00:EXCH]; Reinaldo Penno; Stastny > Richard; timothy.dwight@verizon.com; > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; > Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > Subject: RE: [Speermint] Location Function in SPEERMINT > > Distance is dead IF the proxy does not have strong ties to a > media anchor point. If there is such a media anchor point, > then choosing ones that are close to calling and called > parties will aid in finding shortest routes between parties. > > However, I am not advocating for or against such media > anchors, just simply recognizing that they may exist > depending on a domain's architecture. > > There may be other reasons that peers are directed to one > proxy over another. It is useful for the domain to designate > which proxies peers should use. > > Mike > > > > -----Original Message----- > > From: James McEachern [mailto:jmce@nortel.com] > > Sent: Friday, May 26, 2006 10:44 AM > > To: Reinaldo Penno; Stastny Richard; > > timothy.dwight@verizon.com; Michael Hammer (mhammer); > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > > Sohel Q [CTO]; David Meyer; speermint@ietf.org > > Subject: RE: [Speermint] Location Function in SPEERMINT > > > > >This tells you the SIP proxy to be contacted. It does not > > tell you if > > >this the closest Sip Proxy handling @example.com users. It > also does > > >not tell you if it is the closest proxy to the callee. > > > > Is the ability to "identify the closest proxy" a requirement for > > Speermint? Many people have pointed out that distance is > dead, or at > > least should be, so it isn't clear to me that we really care. The > > Requirements and Terminology draft doesn't explicitly say, but my > > reading of section 5.2 implies this is not a requirement. > > > > That having been said, I don't necessarily have strong views either > > way. I'd just like to be clear on whether or not it is a > requirement. > > > > Jim > > > > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Thursday, May 25, 2006 5:00 PM > > To: Stastny Richard; timothy.dwight@verizon.com; Michael Hammer > > (mhammer); timothy.dwight@verizon.com; Brian Rosen; Francois D. > > Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > > Subject: RE: [Speermint] Location Function in SPEERMINT > > > > I believe it is enough. You could refine it but I might sure of the > > benefits. Maybe this problem was already solved somewhere > and I'm not > > aware. > > > > For example, The UAs would care. > > > > >From RFC3263 > > > > ;; Priority Weight Port Target > > IN SRV 0 1 5060 server1.example.com > > IN SRV 0 2 5060 server2.example.com > > > > This tells you the SIP proxy to be contacted. It does not > tell you if > > this the closest Sip Proxy handling @example.com users. It > also does > > not tell you if it is the closest proxy to the callee. > > > > In the case of a carriers providing VoIP service to a user, if this > > provider A peers with provider B in two different > locations, which one > > to choose to send to forward the call? > > > > Regards, > > > > Reinaldo > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, May 25, 2006 1:52 PM > > > To: Reinaldo Penno; timothy.dwight@verizon.com; Michael Hammer > > (mhammer); > > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > > Sohel Q > > > [CTO]; David Meyer; speermint@ietf.org > > > Subject: Re: [Speermint] Location Function in SPEERMINT > > > > > > Reinaldo said: > > > >That's maybe one of the most important issues. This could be > > complicated > > > >by the geographically dispersed networks with several > entry points. > > > >Although this might be an interesting problem it might be > > a rathole. > > > > > > So you say RFC 3263 is not enough, something is missing? > > > e.g. the geographic location of originating and terminating > > --- what? > > > > > > -SIP proxy? who cares > > > -SBC? > > > -UA? > > > > > > So we are again dealing with SBCs, in this case the > geo-location of > > these > > > -- rats, holes ;-) > > > > > > Richard > > > > > > > > > ________________________________ > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Gesendet: Do 25.05.2006 22:37 > > > An: Stastny Richard; timothy.dwight@verizon.com; Michael Hammer > > (mhammer); > > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > > Sohel Q > > > [CTO]; David Meyer; speermint@ietf.org > > > Betreff: RE: [Speermint] Location Function in SPEERMINT > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, May 25, 2006 1:26 PM > > > > To: timothy.dwight@verizon.com; Michael Hammer (mhammer); > > > > timothy.dwight@verizon.com; Brian Rosen; Francois D. > Menard; Khan, > > > Sohel Q > > > > [CTO]; David Meyer; speermint@ietf.org > > > > Subject: [Speermint] Location Function in SPEERMINT > > > > > > > > Hi all, > > > > > > > > sorry, but I am only able to reply with a short > > statement, because I > > > am > > > > on vacation and have only limited time and bandwitdh (GPRS) > > > > > > > > First, I consider this discussion regarding Infrastructure ENUM, > > LERG > > > and > > > > LNP > > > > important, but in the wrong WG. It should be discussed > in ENUM. WG > > and > > > > not in SPEERMINT > > > > > > > > SPEERMINT is only dealing with Call Routing Data (CRD), which is > > > defined > > > > as the OUTPUT of ENUM or some other means. > > > > > > > > This implies, that the location function (LF) defined in the > > > > achitecture draft happens AFTER an ENUM query and > > therefore cannot > > > > be the part of the LF. > > > > > > > > The LF can only involve the location of the destination > "network" > > > > as defined in SPEERMINT by the use of CRD (which is > > basically a SIP > > > > URI because we are currently talking only SIP in SPEERMINT) > > > > > > > > Of course SPEERMINT needs to define what it considers > > CRD, and AoR > > > > or the ingress point of a network. > > > > > > > > BUT then SPEERMINT needs also to define how the ingress > > point of a > > > > "network" is LOCATED given a SIP AoR. > > > [[Reinaldo]] > > > > > > That's maybe one of the most important issues. This could be > > complicated > > > by the geographically dispersed networks with several > entry points. > > > Although this might be an interesting problem it might be > a rathole. > > > > > > > > > > > > > > Richard > > > > > > > > > > > > ________________________________ > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > Gesendet: Do 25.05.2006 20:17 > > > > An: 'Michael Hammer (mhammer)'; > > timothy.dwight@verizon.com; Stastny > > > > Richard; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, > > Sohel Q [CTO]'; > > > > 'David Meyer'; speermint@ietf.org > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering > Architecture - LF - > > OF > > > - SF > > > > > > > > > > > > > > > > Michael Hammer said: > > > > > > > > > Tim, > > > > > > > > > > The LERG and LNP databases are intrinsically tied to > > the operation > > > of > > > > the > > > > TDM > > > > > infrastructure. Any design that perpatuates these > systems when > > > their > > > > reason > > > > > for being (TDM) goes away is a faulty design. > > > > > > > > OK with me. I only meant to point out that right now I > > have these > > > > capabilities, so recreating them isn't a high priority. > > > > > > > > > > > > > > > > > > DNS and ENUM provides the equivalent information and > > mechanisms to > > > do > > > > what > > > > is > > > > > needed in the IP domain. As such, a design that makes > > dependencies > > > on > > > > legacy > > > > > systems is deficient. I wouldn't support such a kludge. > > > > > > > > Fine. > > > > > > > > I'm a big fan of IP-domain solutions. Specifically > Infrastructure > > > ENUM > > > > looks really handy; my point before was that it's > moreso when used > > in > > > what > > > > Richard called "option 1". The alternative ("option 2") only > > > replicates > > > > the > > > > "kludge" to which I already have access. > > > > > > > > And to be fair to Richard, he did point out (subtly) that > > the latter > > > claim > > > > is a bit myopic. There are existing means by which > VSPs can gain > > > access > > > > to > > > > number portability information relative to national > destinations. > > > They > > > > don't have such access, at least not easily and not > > universally, to > > > number > > > > portability information relative to international > > destinations. If > > > that > > > > could be provided by Infrastructure ENUM (either "option 1" or > > "option > > > 2") > > > > it would be useful and would not simply replicate existing > > > capabilities. > > > > > > > > Bottom line, both options defined by Richard, would add value. > > Option > > > 1 > > > > adds more value but is specific to destinations > > identified by E.164 > > > > numbers or URIs with imbedded E.164 numbers. Which is > > the problem > > > > closest > > to > > > > hand. > > > > > > > > > > > > > > > > > > That said, if there are backward compatibilities during the > > > transition, > > > > where > > > > > some information just happens to be known by external systems, > > such > > > as > > > > you > > > > suggest > > > > > below, I don't see that as a problem. I am just wary > > of ending up > > > with > > > > two > > > > > systems in the end when one would do. > > > > > > > > Isn't it inevitable that for some time, both will > exist? Just as > > the > > > GSTN > > > > and VoIP will coexist for some time, so will their supporting > > > > infrastructure. > > > > > > > > Don't get me wrong. I'm not saying "because I have an > SS7 -based > > > solution > > > > to LNP I don't need an IP -based solution". All I'm > > saying is that > > > when > > > > given the option of using Infrastructure ENUM to > recreate (and in > > the > > > case > > > > of international destinations, extend) the capability I already > > have, > > > and > > > > using it to do that and more, I'm inclined to prefer the latter. > > > > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > > Sent: Wednesday, May 24, 2006 6:19 PM > > > > > To: 'Stastny Richard'; timothy.dwight@verizon.com; > > > > > timothy.dwight@verizon.com; Michael Hammer (mhammer); 'Brian > > Rosen'; > > > > > 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; > > > > > speermint@ietf.org > > > > > Subject: RE: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > OF > > > > > - SF > > > > > > > > > > Richard, > > > > > > > > > > Yes I know I was mixing data and mechanism-to-access-data. > > > > > Still I believe the major point to be correct. In > many parts of > > the > > > > > world there are already mechanisms (associated with > Local Number > > > > > Portability) to determine ownership of an E.164 number, > > hence use > > of > > > > > ENUM for this purpose alone, will be unnecessary. > > > > > > > > > > To be clear, I believe that providing access via > Infrastructure > > ENUM > > > > > to LNP information may be very helpful; but only if > > Infrastructure > > > > > ENUM provides more than just this. > > > > > If an Infrastructure ENUM query can combine (a) > > determination of > > > the > > > > > entity providing service to the destination, (b) > > determination of > > > the > > > > > corresponding LRN, if one exists, and (c) mapping of > > the routable > > > > > number (either the number originally indicated, or > the LRN) to a > > > Layer > > > > > 5 "point of ingress" specified by the entity providing > > service to > > > the > > > > > destination; then Infrastructure ENUM is quite a handy > > mechanism. > > > If > > > > > all it does is (a) then I don't need it. > > > > > > > > > > But in the end this is neither here nor there. I am > > not wedded to > > > any > > > > > specific technology, I just need workable solutions to real > > business > > > > > problems. > > > > > > > > > > Tim > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Wednesday, May 24, 2006 4:38 PM > > > > > To: timothy.dwight@verizon.com; timothy.dwight@verizon.com; > > Michael > > > > > Hammer (mhammer); Brian Rosen; Francois D. Menard; > > Khan, Sohel Q > > > > > [CTO]; David Meyer; speermint@ietf.org > > > > > Subject: Re: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > OF > > > > > - SF > > > > > > > > > > Tim, > > > > > > > > > > thanx for your reply, you are raising some important issues. > > > > > Since it is already midnight here, I will reply to it > in detail > > > > > tomorrow > > > > > > > > > > I am also working on a more detailed analysis and a > draft which > > will > > > > > require even some more time. > > > > > > > > > > Just a quick one: > > > > > > > > > > >In some parts of the world the function provided by "option > > > > > 2" usage of > > > > > >Infrastructure ENUM could be achieved in other ways (e.g., > > > > > the LERG and > > > > > >NPDB in North America) so in those cases Infrastructure ENUM > > > > > might be a > > > > > >superfluous concept; but if that's the right technical > > > > > answer so be it. > > > > > > > > > > Yes and no ;-) > > > > > You are mixing up here the Registry and the ENUM DNS. > > > > > The Registry is the LERG and NPDB (or is derived > from), the ENUM > > DNS > > > > > is the equivalent on IP of the SCP in the PSTN where > > the date is > > > > > downloaded to. > > > > > > > > > > Richard > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > > Gesendet: Mi 24.05.2006 23:00 > > > > > An: Stastny Richard; timothy.dwight@verizon.com; > > 'Michael Hammer > > > > > (mhammer)'; 'Brian Rosen'; 'Francois D. Menard'; > 'Khan, Sohel Q > > > > > [CTO]'; 'David Meyer'; speermint@ietf.org > > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > OF > > > > > - SF > > > > > > > > > > > > > > > > > > > > Richard, > > > > > > > > > > Thank you for the clarification. I understand the > > distinction you > > > are > > > > > making. > > > > > > > > > > My objective is to be able to translate a destination > identifier > > > > > (E.164 number of alphanumeric AoR) into the address of > > a Layer 5 > > > > > entity designated by the organization providing service to the > > > called > > > > > party. With infrastructure/carrier ENUM I could do this (as > > > described > > > > > in your Option 1), but because ENUM is specific to > E.164 numbers > > it > > > > > would only work for E.164 -formatted destination identifiers. > > > > > > > > > > In pictures, your Option 2 seems to me to imply the following: > > > > > > > > > > +----------------+ +----------+ > > > > > E.164 | infrastructure | serving | identify > > > > > | network > > > > > ingress > > > > > destination -->| ENUM |---> carrier --->| ingress > > > > > |---> point > > > > > specified > > > > > identifier | (option 2) | identity | point | > > > by > > > > > serving carrier > > > > > +----------------+ ^ +----------+ > > > > > | > > > > > +----------------+ | > > > > > non-E.164 | map domain in | | > > > > > Destination -->| URI to carrier |--------+ > > > > > Identifier | identity | > > > > > +----------------+ > > > > > > > > > > In some parts of the world the function provided by "option 2" > > usage > > > > > of Infrastructure ENUM could be achieved in other ways > > (e.g., the > > > LERG > > > > > and NPDB in North America) so in those cases > Infrastructure ENUM > > > might > > > > > be a superfluous concept; but if that's the right > > technical answer > > > so > > > > > be it. > > > > > > > > > > The "identify ingress point" function would need to be > > defined. I > > > > > would like it to consider the specified destination > (in addition > > to > > > > > the carrier providing service to that destination); > and I would > > like > > > > > the procedures to be such that the serving carrier > > controls (in a > > > > > reasonably dynamic > > > > > way) the point at which traffic destined to a particular > > > destination, > > > > > enters his network. If those requirements can be met, I think > > this > > > > > approach is workable. > > > > > > > > > > Its biggest drawback is that it precludes a solution > ("option 1" > > > usage > > > > > of Infrastructure ENUM) that is sufficient for the majority of > > > today's > > > > > needs. > > > > > It optimizes for a problem that will exist in the > future at the > > > > > expense of solving problems that exist today. I realize that > > > solving > > > > > today's problems may not be SPEERMINT's focus, or > > (arguably) even > > > > > within its charter, but I would hate to see > > recommendations from > > > > > SPEERMINT preclude or significantly delay solving them. > > > > > > > > > > Suppose we did something like this: > > > > > > > > > > +----------+ [pseudo +----------------+ > > > > > non-E.164 | identify | or real] | infrastructure > > > > > | network > > > > > ingress > > > > > destination -->| "pseudo" |---> E.164 --->| ENUM > > > > > |---> point > > > > > specified > > > > > identifier | E.164 | number | (option 1) | > > > by > > > > > serving carrier > > > > > +----------+ +----------------+ > > > > > > > > > > We could let the ENUM working group define > > Infrastructure ENUM as > > > > > described in your Option 1 (which is as you know already > > > commercially > > > > > available from a few sources) and SPEERMINT could define the > > > "identify > > > > > pseudo E.164" function that in my diagram feeds into > it. This > > > > > function might be as simple as mapping the domain part > > of the URI > > to > > > > > an E.164 number uniquely associated with the network providing > > > service > > > > > to the specified destination. Unless this is a lot > > harder than it > > > > > seems, this shouldn't keep us busy too long :-) > > > > > > > > > > > > > > > Tim > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Wednesday, May 24, 2006 11:16 AM > > > > > To: timothy.dwight@verizon.com; Michael Hammer > (mhammer); Brian > > > > > Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer; > > > > > speermint@ietf.org > > > > > Subject: Re: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > > > OF - SF > > > > > > > > > > Tim, > > > > > > > > > > >> ... the basic idea of Infrastructure ENUM (which > will be used > > for > > > > > >> service providers is to provide a domain name in a > > SIP URI = a > > > > > >> service provider ID > > > > > >(SPID) > > > > > > > > > > >At the risk of asking an off-topic question (realizing that > > > > > ENUM is not > > > > > >within scope for SPEERMINT), can I ask where the idea that > > > > > >Infrastructure ENUM queries return SPIDs, comes from? It is > > > > > my intent > > > > > >to provide a point of interconnection to be used by the > > requesting > > > > > >entity to hand to me a call to the specified number. I do > > > > > not intend > > > > > >that the only meaningful part of the URI returned from the > > > > > ENUM query, > > > > > >be > > > > > the domain name. > > > > > > > > > > thank you for raising this important point. I tried to > > raise this > > > > > some time ago, but got no clear answer > > > > > > > > > > Currently there exist two lines of thought about the usage of > > > > > Infrastructure (and also Carrier ENUM in private trees) > > > > > > > > > > 1. Put in ENUM the ingress point(s) e.g. > > > > > sip:+43xxxx@sbc4711.provider.net 2. > > > > > Put in ENUM the AoR only: e.g. sip:+43xxx@provider.net > > > > > (provider.net is what I meant with SPID) > > > > > > > > > > Most currently prefer option 1, especially in private > > ENUM trees. > > > > > > > > > > IMHO this is the wrong approach: > > > > > > > > > > There should be a clear separation (and it is in the charter) > > > > > between ENUM and SPEERMINT SPEERMINT peering MUST be > > able to work > > > > > standalone and without ENUM. > > > > > > > > > > Option 1 assumes also that the user is entering ALWAYS an > > > > > E.164 number as identifier. > > > > > > > > > > But what if he is entering an AoR? > > > > > > > > > > SPEEMINT peering MUST be able to resolve this too so > > you need to > > > > > find the ingress point independant of ENUM e.g. via RFC3263. > > > > > > > > > > If this MUST be possible, why not enter in (any) ENUM > just the > > > > > AoR, if you must be able to resolve the AoR anyway? > > > > > > > > > > Otherwise you need to manage two mappings separate 1. the > > > > > E.164 to ingress point 2. the AoR mapping to ingress point > > > > > > > > > > this is not a good idea > > > > > > > > > > This is the reason why I would prefer to enter in ENUM > > AoRs only > > > > > the user part in ENUM is always the E.164 number (for privacy > > > > > reasons) the domain part is the SPID, which is mapped > later to > > > > > find the ingress point > > > > > > > > > > the calling user may then also use an alis AoR such as > > > > > sip:name@provider.net > > > > > > > > > > regards > > > > > > > > > > Richard > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > > Gesendet: Mi 24.05.2006 16:46 > > > > > An: Stastny Richard; 'Michael Hammer (mhammer)'; > 'Brian Rosen'; > > > > > 'Francois D. > > > > > Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; > > speermint@ietf.org > > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > > > OF - SF > > > > > > > > > > > > > > > > > > > > Stastny, Richard said: > > > > > > > > > > > ... the basic idea of Infrastructure ENUM (which > will be used > > for > > > > > > service providers is to provide a domain name in a SIP URI > > > > > = a service > > > > > > provider ID > > > > > (SPID) > > > > > > > > > > At the risk of asking an off-topic question (realizing > > that ENUM > > > > > is not within scope for SPEERMINT), can I ask where the > > idea that > > > > > Infrastructure ENUM queries return SPIDs, comes from? > It is my > > > > > intent to provide a point of interconnection to be > used by the > > > > > requesting entity to hand to me a call to the specified > > number. I > > > > > do not intend that the only meaningful part of the > URI returned > > > > > from the ENUM query, be the domain name. > > > > > > > > > > tim > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 14:08:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjgk2-00088m-Ct; Fri, 26 May 2006 14:08:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjgk1-00088g-4V for speermint@ietf.org; Fri, 26 May 2006 14:08:53 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjgjz-0001VP-My for speermint@ietf.org; Fri, 26 May 2006 14:08:53 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k4QI8JYm012870; Fri, 26 May 2006 11:08:19 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k4QI8F7b012869; Fri, 26 May 2006 11:08:15 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 26 May 2006 11:08:15 -0700 From: David Meyer To: Duane Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Message-ID: <20060526180815.GA12777@1-4-5.net> References: <072C5B76F7CEAB488172C6F64B30B5E3018480F1@xmb-rtp-20b.amer.cisco.com> <4477318E.2050305@e164.org> Mime-Version: 1.0 In-Reply-To: <4477318E.2050305@e164.org> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Stastny Richard , speermint@ietf.org, Otmar Lendl , "Khan, Sohel Q \[CTO\]" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1651472191==" Errors-To: speermint-bounces@ietf.org --===============1651472191== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 26, 2006 at 12:49:18PM -0400, Duane wrote: > Michael Hammer (mhammer) wrote: > >Duane, > > > >Your argument depends on the assertion that it is only 20 more bytes of > >data. I don't think we are at a point yet to be able to conclude that > >conclusively. There may be a range of data from very simply to more > >complex. We need to work through this. >=20 > When I said 20 bytes I was being facetious, it could be 2000 bytes or 5M= =20 > for all it really matters because at the end of the day DNS for the most= =20 > part is pulled not pushed so the user only asks for what they need and=20 > only gets what they asked for. I'd check that assumption with any of the root server operators. You might find that many of them have a different concept of what the issues are (at scale).=20 > The problem most have with the idea of a directory service rather then=20 > some kind of replication of the PSTN network is tradition telco type=20 > guys are used to collecting interconnect fees and so they want to come=20 > up with some other way so they can still perform settlements. It's=20 > possible to keep operating in this manner, although it's going to need a= =20 > BGP style system (or least cost rather then shortest path, or perhaps a= =20 > mixing of the two) and some kind of clearing house to facilitate=20 > settlements between carriers. Not to be too much of a contrarian (or perhaps heretic), but what happens when someone puts up "simpletelco.com" which is just just a few SIP proxies and a PSTN g/w, and is done with it? Seems to me that such a service could be made much cheaper (given the mechanisms being bantered around here...just consider the OPEX involved), and more reliable (again, consider the comparative complexity).=20 Now, of course there are quality issues if you're running media over skinny access pipes (that will be true in every case, physics and all), and there are the obvious security, reliability ,etc issues, but the point is that all of this stuff could be OBE'ed in a very simple and straightforward way. Then what? --dmm =20 [Oh yeah, and I forgot to mention that simpletelco.com works with webundleyourservices.com to give you voice, TV, wireless, and Internet, all on one bill, integrated help desk, etc... --dmm] --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEd0QPORgD1qCZ2KcRArSuAJ9ZUBXqiO9dG5/BNbbrBX21nFkmbQCfUfsk fYfhRBMtWD7DuF9vhUhwdEc= =UMIF -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- --===============1651472191== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============1651472191==-- From speermint-bounces@ietf.org Fri May 26 15:11:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjhiN-0001UA-JO; Fri, 26 May 2006 15:11:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjhiM-0001U5-Td for speermint@ietf.org; Fri, 26 May 2006 15:11:14 -0400 Received: from outbound-cpk.frontbridge.com ([207.46.163.16] helo=outbound2-cpk-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjhiL-0007wn-HC for speermint@ietf.org; Fri, 26 May 2006 15:11:14 -0400 Received: from outbound2-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-cpk-R.bigfish.com (Postfix) with ESMTP id 3182F8FBF49; Fri, 26 May 2006 19:11:13 +0000 (UTC) Received: from mail19-cpk-R.bigfish.com (unknown [192.168.21.3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by outbound2-cpk.bigfish.com (Postfix) with ESMTP id 2A3098FBF3E; Fri, 26 May 2006 19:11:13 +0000 (UTC) Received: from mail19-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by mail19-cpk-R.bigfish.com (Postfix) with ESMTP id E2198453898; Fri, 26 May 2006 19:11:12 +0000 (UTC) X-BigFish: V Received: by mail19-cpk (MessageSwitch) id 1148670666312630_31559; Fri, 26 May 2006 19:11:06 +0000 (UCT) Received: from damgwp01.corp.sprint.com (parker2.sprint.com [199.14.91.106]) by mail19-cpk.bigfish.com (Postfix) with ESMTP id 8B4894556EB; Fri, 26 May 2006 19:11:05 +0000 (UTC) Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by damgwp01.corp.sprint.com (Switch-2.1.7/Switch-2.1.0) with ESMTP id k4QJPFZ10973; Fri, 26 May 2006 14:25:15 -0500 (CDT) Received: from plswg02a.ad.sprint.com (PLSWG02A.corp.sprint.com [10.214.11.48]) by kcmgwp02.corp.sprint.com (Switch-2.1.7/Switch-2.1.0) with ESMTP id k4QInYO06532; Fri, 26 May 2006 13:49:50 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by plswg02a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 13:48:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 May 2006 13:48:40 -0500 Message-ID: <978886E57CC1D64EAFAC157B98E36F9E0915944F@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing Issue SIP Interoperablity (Section 4.3: draft-khan-ip-serv-arch-02) Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAANiSfAAGpkGwABFyNDAABcvUoAAA7iiQAELeetAAAMAqIAAO6n1wACEPZuA= From: "Khan, Sohel Q [CTO]" To: "Francois D. Menard" , "Brian Rosen" , "James McEachern" , "Stastny Richard" , , "Michael Hammer \(mhammer\)" , "David Meyer" X-OriginalArrivalTime: 26 May 2006 18:48:42.0271 (UTC) FILETIME=[026D7AF0:01C680F5] X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [Speermint] Closing Issue SIP Interoperablity (Section 4.3: draft-khan-ip-serv-arch-02) X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org =20 Thank you for all suggestions and comments on the SIP Interoperability (Section 4.3: draft-khan-ip-serv-arch-02) paragraph in Speermint Peering Architecture draft. Based on the discussion, I would propose to close the issue by replacing the current paragraph, "SIP Interoperability:TBD" with the following paragraph. "SIP Interoperability: SPEERMINT Signaling Function (SF) in general should support all SIP RFCs identified in the SIP hitchhiker's guide. The SF must minimally support RFC 3261, 3263, 3325, and 3326.=20 A SPEERMINT SIP Profile document would recommend a rationale set of SIP profiles to perform smooth interoperability. The document will also contain information on the population of the header fields, particularly in context with phone numbers (e.164 and non-E.164). A SPEERMINT SIP Flow Document would recommend call flows and establishment of two-way TLS connections." Please do not criticize! Instead, suggest another paragraph or a better version of this paragraph. Sohel Khan, Ph.D. Technology Strategist Sprint-Nextel 913-794-1470 (office) 913-486-3145 (cell) _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 15:49:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjiJN-00023g-MK; Fri, 26 May 2006 15:49:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjiJM-0001yQ-9z for speermint@ietf.org; Fri, 26 May 2006 15:49:28 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjiJJ-0005J1-Vx for speermint@ietf.org; Fri, 26 May 2006 15:49:28 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k4QJnNx00503; Fri, 26 May 2006 15:49:23 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 May 2006 15:49:22 -0400 Message-ID: In-Reply-To: <978886E57CC1D64EAFAC157B98E36F9E0915944F@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing Issue SIP Interoperablity (Section 4.3: draft-khan-ip-serv-arch-02) Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAANiSfAAGpkGwABFyNDAABcvUoAAA7iiQAELeetAAAMAqIAAO6n1wACEPZuAAAmRecA== From: "James McEachern" To: "Khan, Sohel Q [CTO]" , "Francois D. Menard" , X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: [Speermint] RE: Closing Issue SIP Interoperablity (Section 4.3: draft-khan-ip-serv-arch-02) X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Sohel, I believe the minimum list should be RFC 3261, 3323, and 3325 (perhaps = also 3263?). Jim -----Original Message----- From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com]=20 Sent: Friday, May 26, 2006 2:49 PM To: Francois D. Menard; Brian Rosen; McEachern, James [CAR:5N00:EXCH]; = Stastny Richard; speermint@ietf.org; Michael Hammer (mhammer); David = Meyer Subject: Closing Issue SIP Interoperablity (Section 4.3: = draft-khan-ip-serv-arch-02) =20 Thank you for all suggestions and comments on the SIP Interoperability (Section 4.3: draft-khan-ip-serv-arch-02) paragraph in Speermint Peering Architecture draft. Based on the discussion, I would propose to close the issue by replacing the current paragraph, "SIP Interoperability:TBD" with the following paragraph. "SIP Interoperability: SPEERMINT Signaling Function (SF) in general should support all SIP RFCs identified in the SIP hitchhiker's guide. The SF must minimally support RFC 3261, 3263, 3325, and 3326.=20 A SPEERMINT SIP Profile document would recommend a rationale set of SIP profiles to perform smooth interoperability. The document will also contain information on the population of the header fields, particularly in context with phone numbers (e.164 and non-E.164). A SPEERMINT SIP Flow Document would recommend call flows and establishment of two-way TLS connections." Please do not criticize! Instead, suggest another paragraph or a better version of this paragraph. Sohel Khan, Ph.D. Technology Strategist Sprint-Nextel 913-794-1470 (office) 913-486-3145 (cell) _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 16:02:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjiVy-0004kg-8G; Fri, 26 May 2006 16:02:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjiVx-0004kY-FQ for speermint@ietf.org; Fri, 26 May 2006 16:02:29 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjiVv-0007Ba-N0 for speermint@ietf.org; Fri, 26 May 2006 16:02:29 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FjiVD-0008Sl-Ns; Fri, 26 May 2006 15:01:44 -0500 From: "Brian Rosen" To: "'Khan, Sohel Q [CTO]'" , "'Francois D. Menard'" , "'James McEachern'" , "'Stastny Richard'" , , "'Michael Hammer \(mhammer\)'" , "'David Meyer'" Date: Fri, 26 May 2006 16:01:47 -0400 Message-ID: <023301c680ff$3a487240$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <978886E57CC1D64EAFAC157B98E36F9E0915944F@PLSWB08C.ad.sprint.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAANiSfAAGpkGwABFyNDAABcvUoAAA7iiQAELeetAAAMAqIAAO6n1wACEPZuAAApzSgA== X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: [Speermint] RE: Closing Issue SIP Interoperablity (Section 4.3: draft-khan-ip-serv-arch-02) X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Why do you think you can get away with ignoring such things as, say "UPDATE"? Do you really think we can say "implementations should not assume UPDATE will work across the peering point"? I think closing off this issue will require an extended discussion. Brian -----Original Message----- From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] Sent: Friday, May 26, 2006 2:49 PM To: Francois D. Menard; Brian Rosen; James McEachern; Stastny Richard; speermint@ietf.org; Michael Hammer (mhammer); David Meyer Subject: Closing Issue SIP Interoperablity (Section 4.3: draft-khan-ip-serv-arch-02) Thank you for all suggestions and comments on the SIP Interoperability (Section 4.3: draft-khan-ip-serv-arch-02) paragraph in Speermint Peering Architecture draft. Based on the discussion, I would propose to close the issue by replacing the current paragraph, "SIP Interoperability:TBD" with the following paragraph. "SIP Interoperability: SPEERMINT Signaling Function (SF) in general should support all SIP RFCs identified in the SIP hitchhiker's guide. The SF must minimally support RFC 3261, 3263, 3325, and 3326. A SPEERMINT SIP Profile document would recommend a rationale set of SIP profiles to perform smooth interoperability. The document will also contain information on the population of the header fields, particularly in context with phone numbers (e.164 and non-E.164). A SPEERMINT SIP Flow Document would recommend call flows and establishment of two-way TLS connections." Please do not criticize! Instead, suggest another paragraph or a better version of this paragraph. Sohel Khan, Ph.D. Technology Strategist Sprint-Nextel 913-794-1470 (office) 913-486-3145 (cell) _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 16:28:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjiuu-00050e-Mp; Fri, 26 May 2006 16:28:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjiut-0004yA-S9 for speermint@ietf.org; Fri, 26 May 2006 16:28:15 -0400 Received: from outbound-kan.frontbridge.com ([63.161.60.23] helo=outbound2-kan-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjius-0008Rq-Hc for speermint@ietf.org; Fri, 26 May 2006 16:28:15 -0400 Received: from outbound2-kan.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-kan-R.bigfish.com (Postfix) with ESMTP id 27FDE50CDEF; Fri, 26 May 2006 20:28:14 +0000 (UTC) Received: from mail38-kan-R.bigfish.com (unknown [172.18.7.1]) by outbound2-kan.bigfish.com (Postfix) with ESMTP id 1E836514F59; Fri, 26 May 2006 20:28:14 +0000 (UTC) Received: from mail38-kan.bigfish.com (localhost.localdomain [127.0.0.1]) by mail38-kan-R.bigfish.com (Postfix) with ESMTP id 1338819C94F; Fri, 26 May 2006 20:28:14 +0000 (UTC) X-BigFish: V Received: by mail38-kan (MessageSwitch) id 1148675293994286_7995; Fri, 26 May 2006 20:28:13 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail38-kan.bigfish.com (Postfix) with ESMTP id E440719AEC8; Fri, 26 May 2006 20:28:13 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id k4QKQcUi009539; Fri, 26 May 2006 15:26:58 -0500 (CDT) Received: from plswg03a.ad.sprint.com (PLSWG03A.corp.sprint.com [10.214.11.49]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k4QKQb218225; Fri, 26 May 2006 15:26:37 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by plswg03a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 15:25:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 May 2006 15:25:54 -0500 Message-ID: <978886E57CC1D64EAFAC157B98E36F9E09159614@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing Issue SIP Interoperablity (Section 4.3: draft-khan-ip-serv-arch-02) Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAANiSfAAGpkGwABFyNDAABcvUoAAA7iiQAELeetAAAMAqIAAO6n1wACEPZuAAApzSgAAA8TLw From: "Khan, Sohel Q [CTO]" To: "Brian Rosen" , "Francois D. Menard" , "James McEachern" , "Stastny Richard" , , "Michael Hammer \(mhammer\)" , "David Meyer" X-OriginalArrivalTime: 26 May 2006 20:25:56.0030 (UTC) FILETIME=[979E75E0:01C68102] X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Subject: [Speermint] RE: Closing Issue SIP Interoperablity (Section 4.3: draft-khan-ip-serv-arch-02) X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Okay, we will not close this issue! Some RFCs **must** be supported: these are the minimum set of RFCs. Which RFCs are those? {3261, ...} Some RFCs **should** be supported: these RFCs needs to be supported in general. Which RFCs are those? =20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Friday, May 26, 2006 3:02 PM To: Khan, Sohel Q [CTO]; 'Francois D. Menard'; 'James McEachern'; 'Stastny Richard'; speermint@ietf.org; 'Michael Hammer (mhammer)'; 'David Meyer' Subject: RE: Closing Issue SIP Interoperablity (Section 4.3: draft-khan-ip-serv-arch-02) Why do you think you can get away with ignoring such things as, say "UPDATE"? Do you really think we can say "implementations should not assume UPDATE will work across the peering point"? I think closing off this issue will require an extended discussion. Brian -----Original Message----- From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] Sent: Friday, May 26, 2006 2:49 PM To: Francois D. Menard; Brian Rosen; James McEachern; Stastny Richard; speermint@ietf.org; Michael Hammer (mhammer); David Meyer Subject: Closing Issue SIP Interoperablity (Section 4.3: draft-khan-ip-serv-arch-02) =20 Thank you for all suggestions and comments on the SIP Interoperability (Section 4.3: draft-khan-ip-serv-arch-02) paragraph in Speermint Peering Architecture draft. Based on the discussion, I would propose to close the issue by replacing the current paragraph, "SIP Interoperability:TBD" with the following paragraph. "SIP Interoperability: SPEERMINT Signaling Function (SF) in general should support all SIP RFCs identified in the SIP hitchhiker's guide. The SF must minimally support RFC 3261, 3263, 3325, and 3326.=20 A SPEERMINT SIP Profile document would recommend a rationale set of SIP profiles to perform smooth interoperability. The document will also contain information on the population of the header fields, particularly in context with phone numbers (e.164 and non-E.164). A SPEERMINT SIP Flow Document would recommend call flows and establishment of two-way TLS connections." Please do not criticize! Instead, suggest another paragraph or a better version of this paragraph. Sohel Khan, Ph.D. Technology Strategist Sprint-Nextel 913-794-1470 (office) 913-486-3145 (cell) _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 16:54:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjjKY-0000VW-NN; Fri, 26 May 2006 16:54:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjjKX-0000VR-UR for speermint@ietf.org; Fri, 26 May 2006 16:54:45 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjjKV-0003ur-Fh for speermint@ietf.org; Fri, 26 May 2006 16:54:45 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 83BA81A337; Fri, 26 May 2006 22:54:42 +0200 (CEST) Date: Fri, 26 May 2006 22:54:42 +0200 From: Otmar Lendl To: "Michael Hammer (mhammer)" Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Message-ID: <20060526205442.GG1811@nic.at> Mail-Followup-To: Otmar Lendl , "Michael Hammer (mhammer)" , "Khan, Sohel Q [CTO]" , speermint@ietf.org References: <072C5B76F7CEAB488172C6F64B30B5E3018480EA@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3018480EA@xmb-rtp-20b.amer.cisco.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: "Khan, Sohel Q \[CTO\]" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Michael, On 2006/05/26 17:05, "Michael Hammer (mhammer)" wrote: > Otmar, > > I like the way you laid this out. Thanks. > My intent was to have something more like the O(n) scaling you describe > in your first option, only you don't get the information needed to peer > from the DNS, but from the Policy Server handling Subscriptions. Ok, fine. So you need to discover the location of the Policy Server so that you can contact him and subscribe to his policies. If that contact is done via the SIP SUBSCRIBE mechanism, then I guess that means the RFC3263 procedure which involves a NAPTR, SRV and A lookup. In any case: the discovery of the location of such the policy server is certainly a task for the DNS. Maybe this SIP based policy server should be distinct from the normal SIP ingress point (load-balancing, DoS protection, whatever...), so we need some modification to 3263 to distinguish between the two SIP server types. Whereas RFC3263 would look for IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.example.com. your modification might look for IN NAPTR 50 50 "s" "SIPS+D2T:policy" "" _sips._tcp.policy.example.com. or some other suitable variant. That's *very* close to what you can do in my Domain Policy framwork: There the NAPTRs can look something like this: IN NAPTR 50 50 "u" "D2P+SIP:subscribe" "!.*!sip:pol@example.com" . (For some suitable definition of the "subscribe" policy-type.) As an added benefit you get the power of non-terminal naptrs to simplify the hosting of customer SIP domains. > > I don't know what it means to "almost require". Just as with your Read the last mail from Patrick Melampy, he describes a system where a manual setup of the subscription link is a precondition to the exchange of routing information. > DNS-oriented case, if you set up policies and Subscription responses to > be conditioned on the federation that a querier claims to be part of, > backed up by valid certificates signed by that federation, then you can > respond positively without previous manual configurations for that > specific peer. The peer only needs proof that it is part of the > federation. Yes. That's what I'm aiming for. Whether that proof if a TLS cert, access to a VPN, or whatever doesn't matter in the first stages of the process. > Bottom line: It doesn't matter which server type provides the data. Correct. We need a system that's very lightweight for the simple case but flexible and powerful enough to cope with complex and dynamic data as well. I still think that my proposal covers the simple cases and can easly refer to complexer protocols if that's needed. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 21:18:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjnR2-0008Au-4k; Fri, 26 May 2006 21:17:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjnR0-0008Ah-F6 for speermint@ietf.org; Fri, 26 May 2006 21:17:42 -0400 Received: from [205.151.208.34] (helo=fw.tr.xittelecom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjnQz-0000Wy-3Y for speermint@ietf.org; Fri, 26 May 2006 21:17:42 -0400 Received: from [192.168.2.139] (helo=gestionfm) by fw.tr.xittelecom.com with esmtp (Exim 3.36 #1 (Debian)) id 1Fv2iY-0002kE-00; Mon, 26 Jun 2006 21:50:18 -0400 From: "Francois D. Menard" To: "'Otmar Lendl'" , "'Michael Hammer \(mhammer\)'" Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Fri, 26 May 2006 21:15:06 -0400 Message-ID: <01d101c6812b$01412060$8b02a8c0@gestionfm> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20060526151139.GC27495@nic.at> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaA2Le010KfVlOFQ2qE5Is0+ne8LwAUcYkA X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: "'Khan, Sohel Q \[CTO\]'" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > * infrastructure ENUM will be public (if it wants to enable more than = just national peerings). This is why I had the Canadian ENUM trial framework modified to hold non-terminal NAPTRs in Tier 1B which is unlike the US enum trial = framework. F. -- Fran=E7ois D. M=E9nard Projet manager Xit telecom inc. 1350 rue Royale #800 Trois-Rivieres, QC, G9A 4J4 Canada fmenard@xittelecom.com Tel: (819) 374-2556 ext. 268 Fax: (819) 374-0395 Cell: (819) 692-1383 =20 =20 -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at]=20 Sent: 26 mai 2006 11:12 To: Michael Hammer (mhammer) Cc: Khan, Sohel Q [CTO]; speermint@ietf.org Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Michael, On 2006/05/25 18:05, "Michael Hammer (mhammer)" = wrote: >=20 > If an address is advertized in public ENUM or DNS, then it ought not=20 > be unreachable due to use of private networks or NATs, which is the=20 > basis for some of your arguments about why not SIP. We're moving a bit into ENUM WG turf here, but anyway. We're in a bit of a dilemma here regarding infrastructure ENUM: On a national level it's manageable to build a private DNS which only = proper (whatever than means) operators can access. Thus you can build a system = that has the feature "if you can see the URI, then you can reach it". On an international level I consider this to be impossible. The = definitions about who is a proper carrier or not will vary a great deal and I doubt = that a big incumbent in one country will want to directly talk to an upstart = VoIP operator two continents away.=20 Keeping that tree hidden from public view is quite impossible if you consider the scope of the legitimate readers. Consistent selective visibility in a distributed DNS tree is very tricky. [e164.info managed to do so on a small scale, but they use a central DB. = I doubt that you can scale up their system to worldwide, non-centralized = one.] My conclusion from that is that * infrastructure ENUM will be public (if it wants to enable more than just national peerings). * Thus the reachability assumption will have to yield. I wish it weren't so. But I haven't found a way to avoid this = conclusion. Do you see other options? > My thinking was that one would need to progress through a series of=20 > steps/functions where the bootstrap steps are very public, but the=20 > later steps depend on the previous step enabling it. The chicken or=20 > egg problem shouldn't occur for first steps. That's why we put the bootstrapping steps into the DNS. Any other system SPEERMINT will come up with, e.g. some SUBSCRIBE/NOTIFY would fit in = very nicely: the domain policy the can reference this framework as the requirement to reach the destination. > (I do understand your model > where you advertise what is only reachable by a few, but then it is=20 > working as you intended with selective unreachability being part of=20 > your > design.) As I see the market right now, we already have a very selective = reachability on the SIP layer between VoIP operators. I can't see a way to move the state of affairs to "interconnection on = SIP basis between all commercial VoIP-operators worldwide" without either * building a SIP routing protocol complete with transit networks (the BGP model) or=20 * require the possibility of direct connections between all operators worldwide.=20 Determining whether the caller from halfway around the globe is a legitimate operator is massively difficult, thus we end running open servers. (the email model) Thus I think selective reachability on SIP will stay with us for the = medium term. > Hopefully, any delays to call setup occur only because of initial=20 > contact to previously unknown domains. For, previously contacted=20 > domains or for federations that use a central SIP proxy or some=20 > interconnect SIP fabric, the call can be quickly handed to the heavily = > used local contact point for that federation, since they were learned=20 > previous to the call. That sounds good. > Anyway, it may be possible through configuration to address both ways, = > with some heuristic to guide when to transition from the "policy is=20 > simple" approach to the "policy is complex" approach. Even if the policy record just states "this is a carrier URI, calls must = use RFC-SPEERMINT-SUBSCRIPTIONS", this is helpful for callers. I see domain policies as the meta-protocol to bootstrap various other peering mechanisms.=20 The adoption of my draft thus does not preclude further work in = speermint. Quite the contrary. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 21:28:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjnbI-0003y5-7l; Fri, 26 May 2006 21:28:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjnbH-0003y0-Pd for speermint@ietf.org; Fri, 26 May 2006 21:28:19 -0400 Received: from [205.151.208.34] (helo=fw.tr.xittelecom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjnbG-0002Bi-Gp for speermint@ietf.org; Fri, 26 May 2006 21:28:19 -0400 Received: from [192.168.2.139] (helo=gestionfm) by fw.tr.xittelecom.com with esmtp (Exim 3.36 #1 (Debian)) id 1Fv2t2-0002kR-00; Mon, 26 Jun 2006 22:01:08 -0400 From: "Francois D. Menard" To: "'Patrick Melampy'" , "'Otmar Lendl'" Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Fri, 26 May 2006 21:25:52 -0400 Message-ID: <01d201c6812c$84974c90$8b02a8c0@gestionfm> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <03b101c680e4$3e963cd0$0202fea9@acmepacket.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaAyUyv8ZiW0Tq0QsyFoiRh/84djAAGORqAABJ4vrA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: "'Khan, Sohel Q \[CTO\]'" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Patrick Melampy wrote: > An issue does arise when thinking about PSTN numbers. Since many carriers will have an interface to the PSTN, these are not owned by any domain. Thus we may need to expand support for PSTN reachable numbers somehow? One idea would be to also perform subscribe and notify for partial E.164 numbers similar to how it was proposed in the TRIP protocol. I would motion that SPEERMINT only deals with E.164 numbers that are acessible across a SIP NNI. Any E.164 numbers that are also reacheable over TDM is out of scope. F. -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at] Sent: Friday, May 26, 2006 9:36 AM To: Patrick Melampy Cc: 'Michael Hammer (mhammer)'; 'Khan, Sohel Q [CTO]'; speermint@ietf.org Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture On 2006/05/24 17:05, Patrick Melampy wrote: > Subscriptions have other beneficial attributes -- as they can work > across network boundaries and have context. Subscribe/Notify can > deliver a policy that corresponds to a reverse flow of SIP traffic. > Plus the Notification can > provide near real time changes. Also very contextual data can be > included in > the notification -- providing a nice mechanism for automatic > congestion control. > > I like DNS providing LOCATION only, and I like the notion of all other > attributes that have a contextual base to be delivered in a contextual way. I think I can see your point. I still have a serious problem regarding how to bootstrap such a system as * Carriers seem to hate to expose their SIP ingress elements to the open Internet. They firewall, use private address spaces (e.g. GRX) or otherwise block incoming SIP calls before they reach the SIP stack. * we want to avoid a mandatory bilateral configuration of peerings. Could you sketch how a dynamic peering discovery could work with a SIP subscription model? /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 21:39:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjnlm-0006t9-T0; Fri, 26 May 2006 21:39:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjnll-0006t4-Bg for speermint@ietf.org; Fri, 26 May 2006 21:39:09 -0400 Received: from [205.151.208.34] (helo=fw.tr.xittelecom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjnlk-0003mG-3G for speermint@ietf.org; Fri, 26 May 2006 21:39:09 -0400 Received: from [192.168.2.139] (helo=gestionfm) by fw.tr.xittelecom.com with esmtp (Exim 3.36 #1 (Debian)) id 1Fv33W-0002kw-00; Mon, 26 Jun 2006 22:11:58 -0400 From: "Francois D. Menard" To: "'James McEachern'" , "'Khan, Sohel Q [CTO]'" , Date: Fri, 26 May 2006 21:36:48 -0400 Message-ID: <01e001c6812e$07fbf7b0$8b02a8c0@gestionfm> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAANiSfAAGpkGwABFyNDAABcvUoAAA7iiQAELeetAAAMAqIAAO6n1wACEPZuAAAmRecAAMESHQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Subject: [Speermint] RE: Closing Issue SIP Interoperablity (Section 4.3: draft-khan-ip-serv-arch-02) X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Sorry for introducing confusion. So it shall read: =20 SIP Interoperability: SPEERMINT Signaling Function (SF) in general = should support all SIP RFCs identified in the SIP hitchhiker's guide. The SF must minimally support RFC 3261, 3323, 3325, and lastly, 3263, = should peering occur across the Public Internet.=20 I just do not see a mandatory requirement for the SF to support 3263 = whereas peering is not across the big I, say on a private IP network. I believe = the scenario we are excluding is transitive betwene private IP and Public Internet. F. -- Fran=E7ois D. M=E9nard Charg=E9 de projet Xit t=E9l=E9com inc. 1350 rue Royale #800 Trois-Rivi=E8res, QC, G9A 4J4 Canada fmenard@xittelecom.com Tel: (819) 374-2556 ext. 268 Fax: (819) 374-0395 Cell: (819) 692-1383 =20 -----Original Message----- From: James McEachern [mailto:jmce@nortel.com]=20 Sent: 26 mai 2006 15:49 To: Khan, Sohel Q [CTO]; Francois D. Menard; speermint@ietf.org Subject: RE: Closing Issue SIP Interoperablity (Section 4.3: draft-khan-ip-serv-arch-02) Sohel, I believe the minimum list should be RFC 3261, 3323, and 3325 (perhaps = also 3263?). Jim -----Original Message----- From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] Sent: Friday, May 26, 2006 2:49 PM To: Francois D. Menard; Brian Rosen; McEachern, James [CAR:5N00:EXCH]; Stastny Richard; speermint@ietf.org; Michael Hammer (mhammer); David = Meyer Subject: Closing Issue SIP Interoperablity (Section 4.3: draft-khan-ip-serv-arch-02) =20 Thank you for all suggestions and comments on the SIP Interoperability (Section 4.3: draft-khan-ip-serv-arch-02) paragraph in Speermint Peering Architecture draft. Based on the discussion, I would propose to close = the issue by replacing the current paragraph, "SIP Interoperability:TBD" = with the following paragraph. "SIP Interoperability: SPEERMINT Signaling Function (SF) in general = should support all SIP RFCs identified in the SIP hitchhiker's guide. The SF must minimally support RFC 3261, 3263, 3325, and 3326.=20 A SPEERMINT SIP Profile document would recommend a rationale set of SIP profiles to perform smooth interoperability. The document will also = contain information on the population of the header fields, particularly in = context with phone numbers (e.164 and non-E.164). A SPEERMINT SIP Flow Document would recommend call flows and = establishment of two-way TLS connections." Please do not criticize! Instead, suggest another paragraph or a better version of this paragraph. Sohel Khan, Ph.D. Technology Strategist Sprint-Nextel 913-794-1470 (office) 913-486-3145 (cell) _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri May 26 22:35:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjodV-0002BU-HA; Fri, 26 May 2006 22:34:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjodT-0002BO-UO for speermint@ietf.org; Fri, 26 May 2006 22:34:39 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjodR-0001G4-RV for speermint@ietf.org; Fri, 26 May 2006 22:34:39 -0400 Received: from PMelampy [68.189.242.21] by acmepacket.com with ESMTP (SMTPD-9.03) id AAA702C8; Fri, 26 May 2006 22:34:15 -0400 Message-Id: <200605262234192.SM03788@PMelampy> From: "Patrick Melampy" To: "'Brian Rosen'" , "'Michael Hammer \(mhammer\)'" , "'James McEachern'" , Subject: RE: [Speermint] Location Function in SPEERMINT Date: Fri, 26 May 2006 22:34:14 -0400 Message-ID: <03fb01c68136$0c37d300$0202fea9@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAATumxgAG4BNwABEZoVAADQ2DIAAC1z/9AAGrFeAACZ2pfQABju7wACHfcEAAAbB9IAAK1HH6AAC9BtAAAGOAdAAAMvVgACTEanAAAMf18AAA1j4AAAEyrIAAAQ+GAAADlElAAAjeTVA= In-Reply-To: <01ad01c680ef$43a00f20$640fa8c0@cis.neustar.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: a4ba408990f83ef962b4876088b8c71a Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I think SPEERMINT needs to help us locate and find adjacent proxies, and attributes about those proxies. This will enable peering to be more flexible and automatic -- as opposed to sharing lots of provisioning data and using static proxy definitions (which is the way carriers peer today). I also think that the attributes of proxies should include: Reachable domains Permitted transaction rates Permitted quantity of sessions/bandwidth This is my opinion of course -- based on extensive practice. Any subset of this type of information would be ok. Notice that I did not include any media anchor's, or other methods. I do believe that you are right, this should not be required. Also I believe that the originating network has total control over selection of the "crossing point". -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Friday, May 26, 2006 2:07 PM To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'James McEachern'; speermint@ietf.org Subject: RE: [Speermint] Location Function in SPEERMINT I think the question we want to ask in SPEERMINT is: do we care about any of this? It seems to me that the originating network, and the terminating network, will arrange their signaling through designated peering points. They can, if they want, designate media peering points by using SBCs or other mechanisms that effectively rewrite the SIP message bodies. I think that we can ignore that at the peering point, because when the call gets to the peering point, it's going to have the SDP offer in the INVITE; the media anchor has been decided. Now, in many cases, I expect that as part of its network, the originating network is going to do some kind of lookup (ENUM) that will tell it the destination network, and that could influence its choice of media anchor if it's doing things like that. The point is that I don't think SPEERMINT standardizes that behavior; it's a single element (some SIP proxy) making an internal decision, and routing the call within its network appropriately. Similarly, when the terminating network gets the call, it can make an internal decision to direct the media to some box in its network, which will show up in the answer SDP. Again, that is it's proxy making an internal routing decision. BETWEEN networks, which where we are working, I don't think we are doing any media routing beyond the normal SIP and IP packet stuff. Do I have that right? -----Original Message----- From: Patrick Melampy [mailto:PMelampy@acmepacket.com] Sent: Friday, May 26, 2006 12:23 PM To: 'Michael Hammer (mhammer)'; 'James McEachern'; speermint@ietf.org Subject: RE: [Speermint] Location Function in SPEERMINT One of the best arguments for the "composed" SBC is that if your going to need to locate the "closest media anchor", what better way than associating it with a proxy. If the requirement is to NOT manage the media, but rather let natural BGP4 style internetworking mechanisms route the media optimally, then there is no need to bother with identifying a location of a media anchor. So the real issue here in terms of requirements is: Will Carriers be able to use the autonomous system path (AS_PATH) for delivery and routing of media packets from all sources (customers and suppliers) to all sources (customers and suppliers.) Another way to say the same thing more simply, will carriers put all of the signaled media onto the public internet -- as it's the only internetwork available today. If the answer is NO, then there will need to be media anchors and NAT devices. The location of these devices will be important to the efficiency and manageability of the service offering. The signaling and routing components of the SIP network MUST be aware of the media path, as the signaling plane is establishing the media path. This awareness and state suggest that there needs to be a relationship between the signaling plane and media anchor that is understood and close. I'm going to suggest here that the location of the proxy (the nearest proxy) be a substitute for the nearest media anchor point. -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Friday, May 26, 2006 11:51 AM To: James McEachern; speermint@ietf.org Subject: RE: [Speermint] Location Function in SPEERMINT I think I have lost track of what "it" is. I don't think "it" is the ability to identify a proxy that a peer should use based on location. "It" may be the ability to identify a proxy that a peer should use based on the peer identity or affiliation (federation). "Location" has geographic baggage when perhaps selective "discovery" is really what is meant. Please correct me as I may have gotten disoriented with the different mail threads. Mike > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com] > Sent: Friday, May 26, 2006 11:16 AM > To: Michael Hammer (mhammer); speermint@ietf.org > Subject: RE: [Speermint] Location Function in SPEERMINT > > So are you saying that it should be a requirement? > > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, May 26, 2006 10:52 AM > To: McEachern, James [CAR:5N00:EXCH]; Reinaldo Penno; Stastny > Richard; timothy.dwight@verizon.com; > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; > Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > Subject: RE: [Speermint] Location Function in SPEERMINT > > Distance is dead IF the proxy does not have strong ties to a > media anchor point. If there is such a media anchor point, > then choosing ones that are close to calling and called > parties will aid in finding shortest routes between parties. > > However, I am not advocating for or against such media > anchors, just simply recognizing that they may exist > depending on a domain's architecture. > > There may be other reasons that peers are directed to one > proxy over another. It is useful for the domain to designate > which proxies peers should use. > > Mike > > > > -----Original Message----- > > From: James McEachern [mailto:jmce@nortel.com] > > Sent: Friday, May 26, 2006 10:44 AM > > To: Reinaldo Penno; Stastny Richard; > > timothy.dwight@verizon.com; Michael Hammer (mhammer); > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > > Sohel Q [CTO]; David Meyer; speermint@ietf.org > > Subject: RE: [Speermint] Location Function in SPEERMINT > > > > >This tells you the SIP proxy to be contacted. It does not > > tell you if > > >this the closest Sip Proxy handling @example.com users. It > also does > > >not tell you if it is the closest proxy to the callee. > > > > Is the ability to "identify the closest proxy" a requirement for > > Speermint? Many people have pointed out that distance is > dead, or at > > least should be, so it isn't clear to me that we really care. The > > Requirements and Terminology draft doesn't explicitly say, but my > > reading of section 5.2 implies this is not a requirement. > > > > That having been said, I don't necessarily have strong views either > > way. I'd just like to be clear on whether or not it is a > requirement. > > > > Jim > > > > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Thursday, May 25, 2006 5:00 PM > > To: Stastny Richard; timothy.dwight@verizon.com; Michael Hammer > > (mhammer); timothy.dwight@verizon.com; Brian Rosen; Francois D. > > Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > > Subject: RE: [Speermint] Location Function in SPEERMINT > > > > I believe it is enough. You could refine it but I might sure of the > > benefits. Maybe this problem was already solved somewhere > and I'm not > > aware. > > > > For example, The UAs would care. > > > > >From RFC3263 > > > > ;; Priority Weight Port Target > > IN SRV 0 1 5060 server1.example.com > > IN SRV 0 2 5060 server2.example.com > > > > This tells you the SIP proxy to be contacted. It does not > tell you if > > this the closest Sip Proxy handling @example.com users. It > also does > > not tell you if it is the closest proxy to the callee. > > > > In the case of a carriers providing VoIP service to a user, if this > > provider A peers with provider B in two different > locations, which one > > to choose to send to forward the call? > > > > Regards, > > > > Reinaldo > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, May 25, 2006 1:52 PM > > > To: Reinaldo Penno; timothy.dwight@verizon.com; Michael Hammer > > (mhammer); > > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > > Sohel Q > > > [CTO]; David Meyer; speermint@ietf.org > > > Subject: Re: [Speermint] Location Function in SPEERMINT > > > > > > Reinaldo said: > > > >That's maybe one of the most important issues. This could be > > complicated > > > >by the geographically dispersed networks with several > entry points. > > > >Although this might be an interesting problem it might be > > a rathole. > > > > > > So you say RFC 3263 is not enough, something is missing? > > > e.g. the geographic location of originating and terminating > > --- what? > > > > > > -SIP proxy? who cares > > > -SBC? > > > -UA? > > > > > > So we are again dealing with SBCs, in this case the > geo-location of > > these > > > -- rats, holes ;-) > > > > > > Richard > > > > > > > > > ________________________________ > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Gesendet: Do 25.05.2006 22:37 > > > An: Stastny Richard; timothy.dwight@verizon.com; Michael Hammer > > (mhammer); > > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > > Sohel Q > > > [CTO]; David Meyer; speermint@ietf.org > > > Betreff: RE: [Speermint] Location Function in SPEERMINT > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, May 25, 2006 1:26 PM > > > > To: timothy.dwight@verizon.com; Michael Hammer (mhammer); > > > > timothy.dwight@verizon.com; Brian Rosen; Francois D. > Menard; Khan, > > > Sohel Q > > > > [CTO]; David Meyer; speermint@ietf.org > > > > Subject: [Speermint] Location Function in SPEERMINT > > > > > > > > Hi all, > > > > > > > > sorry, but I am only able to reply with a short > > statement, because I > > > am > > > > on vacation and have only limited time and bandwitdh (GPRS) > > > > > > > > First, I consider this discussion regarding Infrastructure ENUM, > > LERG > > > and > > > > LNP > > > > important, but in the wrong WG. It should be discussed > in ENUM. WG > > and > > > > not in SPEERMINT > > > > > > > > SPEERMINT is only dealing with Call Routing Data (CRD), which is > > > defined > > > > as the OUTPUT of ENUM or some other means. > > > > > > > > This implies, that the location function (LF) defined in the > > > > achitecture draft happens AFTER an ENUM query and > > therefore cannot > > > > be the part of the LF. > > > > > > > > The LF can only involve the location of the destination > "network" > > > > as defined in SPEERMINT by the use of CRD (which is > > basically a SIP > > > > URI because we are currently talking only SIP in SPEERMINT) > > > > > > > > Of course SPEERMINT needs to define what it considers > > CRD, and AoR > > > > or the ingress point of a network. > > > > > > > > BUT then SPEERMINT needs also to define how the ingress > > point of a > > > > "network" is LOCATED given a SIP AoR. > > > [[Reinaldo]] > > > > > > That's maybe one of the most important issues. This could be > > complicated > > > by the geographically dispersed networks with several > entry points. > > > Although this might be an interesting problem it might be > a rathole. > > > > > > > > > > > > > > Richard > > > > > > > > > > > > ________________________________ > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > Gesendet: Do 25.05.2006 20:17 > > > > An: 'Michael Hammer (mhammer)'; > > timothy.dwight@verizon.com; Stastny > > > > Richard; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, > > Sohel Q [CTO]'; > > > > 'David Meyer'; speermint@ietf.org > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering > Architecture - LF - > > OF > > > - SF > > > > > > > > > > > > > > > > Michael Hammer said: > > > > > > > > > Tim, > > > > > > > > > > The LERG and LNP databases are intrinsically tied to > > the operation > > > of > > > > the > > > > TDM > > > > > infrastructure. Any design that perpatuates these > systems when > > > their > > > > reason > > > > > for being (TDM) goes away is a faulty design. > > > > > > > > OK with me. I only meant to point out that right now I > > have these > > > > capabilities, so recreating them isn't a high priority. > > > > > > > > > > > > > > > > > > DNS and ENUM provides the equivalent information and > > mechanisms to > > > do > > > > what > > > > is > > > > > needed in the IP domain. As such, a design that makes > > dependencies > > > on > > > > legacy > > > > > systems is deficient. I wouldn't support such a kludge. > > > > > > > > Fine. > > > > > > > > I'm a big fan of IP-domain solutions. Specifically > Infrastructure > > > ENUM > > > > looks really handy; my point before was that it's > moreso when used > > in > > > what > > > > Richard called "option 1". The alternative ("option 2") only > > > replicates > > > > the > > > > "kludge" to which I already have access. > > > > > > > > And to be fair to Richard, he did point out (subtly) that > > the latter > > > claim > > > > is a bit myopic. There are existing means by which > VSPs can gain > > > access > > > > to > > > > number portability information relative to national > destinations. > > > They > > > > don't have such access, at least not easily and not > > universally, to > > > number > > > > portability information relative to international > > destinations. If > > > that > > > > could be provided by Infrastructure ENUM (either "option 1" or > > "option > > > 2") > > > > it would be useful and would not simply replicate existing > > > capabilities. > > > > > > > > Bottom line, both options defined by Richard, would add value. > > Option > > > 1 > > > > adds more value but is specific to destinations > > identified by E.164 > > > > numbers or URIs with imbedded E.164 numbers. Which is > > the problem > > > > closest > > to > > > > hand. > > > > > > > > > > > > > > > > > > That said, if there are backward compatibilities during the > > > transition, > > > > where > > > > > some information just happens to be known by external systems, > > such > > > as > > > > you > > > > suggest > > > > > below, I don't see that as a problem. I am just wary > > of ending up > > > with > > > > two > > > > > systems in the end when one would do. > > > > > > > > Isn't it inevitable that for some time, both will > exist? Just as > > the > > > GSTN > > > > and VoIP will coexist for some time, so will their supporting > > > > infrastructure. > > > > > > > > Don't get me wrong. I'm not saying "because I have an > SS7 -based > > > solution > > > > to LNP I don't need an IP -based solution". All I'm > > saying is that > > > when > > > > given the option of using Infrastructure ENUM to > recreate (and in > > the > > > case > > > > of international destinations, extend) the capability I already > > have, > > > and > > > > using it to do that and more, I'm inclined to prefer the latter. > > > > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > > Sent: Wednesday, May 24, 2006 6:19 PM > > > > > To: 'Stastny Richard'; timothy.dwight@verizon.com; > > > > > timothy.dwight@verizon.com; Michael Hammer (mhammer); 'Brian > > Rosen'; > > > > > 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; > > > > > speermint@ietf.org > > > > > Subject: RE: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > OF > > > > > - SF > > > > > > > > > > Richard, > > > > > > > > > > Yes I know I was mixing data and mechanism-to-access-data. > > > > > Still I believe the major point to be correct. In > many parts of > > the > > > > > world there are already mechanisms (associated with > Local Number > > > > > Portability) to determine ownership of an E.164 number, > > hence use > > of > > > > > ENUM for this purpose alone, will be unnecessary. > > > > > > > > > > To be clear, I believe that providing access via > Infrastructure > > ENUM > > > > > to LNP information may be very helpful; but only if > > Infrastructure > > > > > ENUM provides more than just this. > > > > > If an Infrastructure ENUM query can combine (a) > > determination of > > > the > > > > > entity providing service to the destination, (b) > > determination of > > > the > > > > > corresponding LRN, if one exists, and (c) mapping of > > the routable > > > > > number (either the number originally indicated, or > the LRN) to a > > > Layer > > > > > 5 "point of ingress" specified by the entity providing > > service to > > > the > > > > > destination; then Infrastructure ENUM is quite a handy > > mechanism. > > > If > > > > > all it does is (a) then I don't need it. > > > > > > > > > > But in the end this is neither here nor there. I am > > not wedded to > > > any > > > > > specific technology, I just need workable solutions to real > > business > > > > > problems. > > > > > > > > > > Tim > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Wednesday, May 24, 2006 4:38 PM > > > > > To: timothy.dwight@verizon.com; timothy.dwight@verizon.com; > > Michael > > > > > Hammer (mhammer); Brian Rosen; Francois D. Menard; > > Khan, Sohel Q > > > > > [CTO]; David Meyer; speermint@ietf.org > > > > > Subject: Re: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > OF > > > > > - SF > > > > > > > > > > Tim, > > > > > > > > > > thanx for your reply, you are raising some important issues. > > > > > Since it is already midnight here, I will reply to it > in detail > > > > > tomorrow > > > > > > > > > > I am also working on a more detailed analysis and a > draft which > > will > > > > > require even some more time. > > > > > > > > > > Just a quick one: > > > > > > > > > > >In some parts of the world the function provided by "option > > > > > 2" usage of > > > > > >Infrastructure ENUM could be achieved in other ways (e.g., > > > > > the LERG and > > > > > >NPDB in North America) so in those cases Infrastructure ENUM > > > > > might be a > > > > > >superfluous concept; but if that's the right technical > > > > > answer so be it. > > > > > > > > > > Yes and no ;-) > > > > > You are mixing up here the Registry and the ENUM DNS. > > > > > The Registry is the LERG and NPDB (or is derived > from), the ENUM > > DNS > > > > > is the equivalent on IP of the SCP in the PSTN where > > the date is > > > > > downloaded to. > > > > > > > > > > Richard > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > > Gesendet: Mi 24.05.2006 23:00 > > > > > An: Stastny Richard; timothy.dwight@verizon.com; > > 'Michael Hammer > > > > > (mhammer)'; 'Brian Rosen'; 'Francois D. Menard'; > 'Khan, Sohel Q > > > > > [CTO]'; 'David Meyer'; speermint@ietf.org > > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > OF > > > > > - SF > > > > > > > > > > > > > > > > > > > > Richard, > > > > > > > > > > Thank you for the clarification. I understand the > > distinction you > > > are > > > > > making. > > > > > > > > > > My objective is to be able to translate a destination > identifier > > > > > (E.164 number of alphanumeric AoR) into the address of > > a Layer 5 > > > > > entity designated by the organization providing service to the > > > called > > > > > party. With infrastructure/carrier ENUM I could do this (as > > > described > > > > > in your Option 1), but because ENUM is specific to > E.164 numbers > > it > > > > > would only work for E.164 -formatted destination identifiers. > > > > > > > > > > In pictures, your Option 2 seems to me to imply the following: > > > > > > > > > > +----------------+ +----------+ > > > > > E.164 | infrastructure | serving | identify > > > > > | network > > > > > ingress > > > > > destination -->| ENUM |---> carrier --->| ingress > > > > > |---> point > > > > > specified > > > > > identifier | (option 2) | identity | point | > > > by > > > > > serving carrier > > > > > +----------------+ ^ +----------+ > > > > > | > > > > > +----------------+ | > > > > > non-E.164 | map domain in | | > > > > > Destination -->| URI to carrier |--------+ > > > > > Identifier | identity | > > > > > +----------------+ > > > > > > > > > > In some parts of the world the function provided by "option 2" > > usage > > > > > of Infrastructure ENUM could be achieved in other ways > > (e.g., the > > > LERG > > > > > and NPDB in North America) so in those cases > Infrastructure ENUM > > > might > > > > > be a superfluous concept; but if that's the right > > technical answer > > > so > > > > > be it. > > > > > > > > > > The "identify ingress point" function would need to be > > defined. I > > > > > would like it to consider the specified destination > (in addition > > to > > > > > the carrier providing service to that destination); > and I would > > like > > > > > the procedures to be such that the serving carrier > > controls (in a > > > > > reasonably dynamic > > > > > way) the point at which traffic destined to a particular > > > destination, > > > > > enters his network. If those requirements can be met, I think > > this > > > > > approach is workable. > > > > > > > > > > Its biggest drawback is that it precludes a solution > ("option 1" > > > usage > > > > > of Infrastructure ENUM) that is sufficient for the majority of > > > today's > > > > > needs. > > > > > It optimizes for a problem that will exist in the > future at the > > > > > expense of solving problems that exist today. I realize that > > > solving > > > > > today's problems may not be SPEERMINT's focus, or > > (arguably) even > > > > > within its charter, but I would hate to see > > recommendations from > > > > > SPEERMINT preclude or significantly delay solving them. > > > > > > > > > > Suppose we did something like this: > > > > > > > > > > +----------+ [pseudo +----------------+ > > > > > non-E.164 | identify | or real] | infrastructure > > > > > | network > > > > > ingress > > > > > destination -->| "pseudo" |---> E.164 --->| ENUM > > > > > |---> point > > > > > specified > > > > > identifier | E.164 | number | (option 1) | > > > by > > > > > serving carrier > > > > > +----------+ +----------------+ > > > > > > > > > > We could let the ENUM working group define > > Infrastructure ENUM as > > > > > described in your Option 1 (which is as you know already > > > commercially > > > > > available from a few sources) and SPEERMINT could define the > > > "identify > > > > > pseudo E.164" function that in my diagram feeds into > it. This > > > > > function might be as simple as mapping the domain part > > of the URI > > to > > > > > an E.164 number uniquely associated with the network providing > > > service > > > > > to the specified destination. Unless this is a lot > > harder than it > > > > > seems, this shouldn't keep us busy too long :-) > > > > > > > > > > > > > > > Tim > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Wednesday, May 24, 2006 11:16 AM > > > > > To: timothy.dwight@verizon.com; Michael Hammer > (mhammer); Brian > > > > > Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer; > > > > > speermint@ietf.org > > > > > Subject: Re: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > > > OF - SF > > > > > > > > > > Tim, > > > > > > > > > > >> ... the basic idea of Infrastructure ENUM (which > will be used > > for > > > > > >> service providers is to provide a domain name in a > > SIP URI = a > > > > > >> service provider ID > > > > > >(SPID) > > > > > > > > > > >At the risk of asking an off-topic question (realizing that > > > > > ENUM is not > > > > > >within scope for SPEERMINT), can I ask where the idea that > > > > > >Infrastructure ENUM queries return SPIDs, comes from? It is > > > > > my intent > > > > > >to provide a point of interconnection to be used by the > > requesting > > > > > >entity to hand to me a call to the specified number. I do > > > > > not intend > > > > > >that the only meaningful part of the URI returned from the > > > > > ENUM query, > > > > > >be > > > > > the domain name. > > > > > > > > > > thank you for raising this important point. I tried to > > raise this > > > > > some time ago, but got no clear answer > > > > > > > > > > Currently there exist two lines of thought about the usage of > > > > > Infrastructure (and also Carrier ENUM in private trees) > > > > > > > > > > 1. Put in ENUM the ingress point(s) e.g. > > > > > sip:+43xxxx@sbc4711.provider.net 2. > > > > > Put in ENUM the AoR only: e.g. sip:+43xxx@provider.net > > > > > (provider.net is what I meant with SPID) > > > > > > > > > > Most currently prefer option 1, especially in private > > ENUM trees. > > > > > > > > > > IMHO this is the wrong approach: > > > > > > > > > > There should be a clear separation (and it is in the charter) > > > > > between ENUM and SPEERMINT SPEERMINT peering MUST be > > able to work > > > > > standalone and without ENUM. > > > > > > > > > > Option 1 assumes also that the user is entering ALWAYS an > > > > > E.164 number as identifier. > > > > > > > > > > But what if he is entering an AoR? > > > > > > > > > > SPEEMINT peering MUST be able to resolve this too so > > you need to > > > > > find the ingress point independant of ENUM e.g. via RFC3263. > > > > > > > > > > If this MUST be possible, why not enter in (any) ENUM > just the > > > > > AoR, if you must be able to resolve the AoR anyway? > > > > > > > > > > Otherwise you need to manage two mappings separate 1. the > > > > > E.164 to ingress point 2. the AoR mapping to ingress point > > > > > > > > > > this is not a good idea > > > > > > > > > > This is the reason why I would prefer to enter in ENUM > > AoRs only > > > > > the user part in ENUM is always the E.164 number (for privacy > > > > > reasons) the domain part is the SPID, which is mapped > later to > > > > > find the ingress point > > > > > > > > > > the calling user may then also use an alis AoR such as > > > > > sip:name@provider.net > > > > > > > > > > regards > > > > > > > > > > Richard > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > > Gesendet: Mi 24.05.2006 16:46 > > > > > An: Stastny Richard; 'Michael Hammer (mhammer)'; > 'Brian Rosen'; > > > > > 'Francois D. > > > > > Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; > > speermint@ietf.org > > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > > > OF - SF > > > > > > > > > > > > > > > > > > > > Stastny, Richard said: > > > > > > > > > > > ... the basic idea of Infrastructure ENUM (which > will be used > > for > > > > > > service providers is to provide a domain name in a SIP URI > > > > > = a service > > > > > > provider ID > > > > > (SPID) > > > > > > > > > > At the risk of asking an off-topic question (realizing > > that ENUM > > > > > is not within scope for SPEERMINT), can I ask where the > > idea that > > > > > Infrastructure ENUM queries return SPIDs, comes from? > It is my > > > > > intent to provide a point of interconnection to be > used by the > > > > > requesting entity to hand to me a call to the specified > > number. I > > > > > do not intend that the only meaningful part of the > URI returned > > > > > from the ENUM query, be the domain name. > > > > > > > > > > tim > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat May 27 03:33:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjtI9-0003JE-1i; Sat, 27 May 2006 03:32:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjtI7-0003J9-6e for speermint@ietf.org; Sat, 27 May 2006 03:32:56 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FjtI4-0001IN-N8 for speermint@ietf.org; Sat, 27 May 2006 03:32:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Sat, 27 May 2006 09:36:47 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A7F@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaAyUyv8ZiW0Tq0QsyFoiRh/84djAAGORqAABJ4vrAADL2EkA== From: "Stastny Richard" To: "Francois D. Menard" , "Patrick Melampy" X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org >Francois D. Menard wrote >>Patrick Melampy wrote: >> An issue does arise when thinking about PSTN numbers. Since many = carriers >>will have an interface to the PSTN, these are not owned by any domain. = Thus >>we may need to expand support for PSTN reachable numbers somehow? One = idea >>would be to also perform subscribe and notify for partial E.164 = numbers >>similar to how it was proposed in the TRIP protocol. >I would motion that SPEERMINT only deals with E.164 numbers that are >acessible across a SIP NNI. Any E.164 numbers that are also reacheable = over >TDM is out of scope. IMHO SPEERMINT does not deal with E.164 numbers at all in routing, it is = out of scope This is ENUM WG scope the only issue regading E.164 could be how calls originally originating and terminating E.164 are dealt with in the header fields in the = Signallng Function And I definitely do not want to go down the bumpy road using SPEERMINT to discuss how to interconnect and locate SIP transit networks for PSTN networks (e.g. using TRIP)=20 Richard -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at] Sent: Friday, May 26, 2006 9:36 AM To: Patrick Melampy Cc: 'Michael Hammer (mhammer)'; 'Khan, Sohel Q [CTO]'; = speermint@ietf.org Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture On 2006/05/24 17:05, Patrick Melampy wrote: > Subscriptions have other beneficial attributes -- as they can work > across network boundaries and have context. Subscribe/Notify can > deliver a policy that corresponds to a reverse flow of SIP traffic. > Plus the Notification can > provide near real time changes. Also very contextual data can be > included in > the notification -- providing a nice mechanism for automatic > congestion control. > > I like DNS providing LOCATION only, and I like the notion of all other > attributes that have a contextual base to be delivered in a contextual way. I think I can see your point. I still have a serious problem regarding how to bootstrap such a system = as * Carriers seem to hate to expose their SIP ingress elements to the open Internet. They firewall, use private address spaces (e.g. GRX) or otherwise block incoming SIP calls before they reach the SIP stack. * we want to avoid a mandatory bilateral configuration of peerings. =20 Could you sketch how a dynamic peering discovery could work with a SIP subscription model? /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat May 27 04:29:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjuAn-0006Fr-8g; Sat, 27 May 2006 04:29:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjuAl-0006Fl-WB for speermint@ietf.org; Sat, 27 May 2006 04:29:23 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjuAk-0007m5-Ej for speermint@ietf.org; Sat, 27 May 2006 04:29:23 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 13F5F1A395; Sat, 27 May 2006 10:29:21 +0200 (CEST) Date: Sat, 27 May 2006 10:29:20 +0200 From: Otmar Lendl To: Patrick Melampy Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Message-ID: <20060527082920.GI1811@nic.at> Mail-Followup-To: Otmar Lendl , Patrick Melampy , "'Khan, Sohel Q [CTO]'" , speermint@ietf.org References: <20060526133546.GB27495@nic.at> <03b101c680e4$3e963cd0$0202fea9@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03b101c680e4$3e963cd0$0202fea9@acmepacket.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: "'Khan, Sohel Q \[CTO\]'" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/05/26 18:05, Patrick Melampy wrote: > I suppose like in any distributed routing protocol, there are some chicken > an egg issues. But consider the following. > > PREREQUISITES: > 1.) You know the destination DOMAIN from either ENUM or other means. [...] > > This technique is very similar to TRIP, only its for DOMAINS and not partial > E.164 numbers. [...] > Obviously, the data set could get large, as the list of domains can be > really big. There are some possibilities here... Let's do a quick estimate on the number of domains involved: Right now, operators usually give customers URIs of the form @. As long as this is the state of affairs, we're fine as the number of providers is quite finite (a few thousands, perhaps). This is like the state of affairs with respect to email, anno 1990. Back then customers started to notice that if they use their own domain for email, then they can switch providers without having to change their email address. Thus a *lot* of people opted to use their own domain for email. My guess is that the same will happen to SIP. Once customers print their SIP uris on business cards, they will want to use their own domains. If providers won't support that feature then I suspect that the regulators will step in and mandate an URI portability solution just as they did in the PSTN with respect to numbers from number blocks. (This could get really nasty protocol-wise, so I guess using customer- owned domains is the far better and likelier solution to the porting question.) So: Anything we come up with here in SPEERMINT needs to cope with a scenario where the use of customer domains in SIP URIs is just as widespread as it is for email. How many domains are used for email? That's hard to say. There are about 60 million gTLD domains and probably more than 20 ccTLD ones. Assuming that only a tenth of that is used for email we're at 8 million domains. Given the exponential growth any system which doesn't scale to at least 10 million domains will be obsolete before the ink is dry on the RFC. So what happens if we do some sort of BGP or TRIP with domains? Let's say we need at least 100 bytes of state information per domain. That makes a full routing table 1 GB worth of data. That also means that a new border element needs to exchange that amount of data with its peers before it has learned the current state of the routing table. That is some serious amount of data. > 1.) Have notification point to a published document, and the document lists > all of the relevant reachability in real time. Thus any change to the > document would generate a NOTIFICATION. + a download of up to 1 GB per peer. > 2.) User partial domains, broken up by the "dots". This may allow some > wildcarding to reduce the number of domains. For instance, a carrier like > Verizon may have many 100's of domains attached to it, and version is > willing to route and manage SIP traffic to any of them. The NOTIFY could > contain something like: Verizon.com or *.verizon.com to indicate that any > domain in Verizon is reachable. That's helpful if a provider uses subdomains for internal purposes, but that won't help you with customer owned domains. > This technique may work -- and fit nicely into an existing protocol. All we > would need to do is define the data models (XML?) and or documents for > exchanging. I think this technique can work -- if you add an aggregation step before the routing scheme. Take another look at BGP: there you have the concept of an Autonomous System and not only that of prefixes. Maybe you need something similar. One approach to cope with hosted SIP domains could be to use the hostnames as found in SRV records. E.g. for settings like _sip._tcp.customer.domain IN SRV 10 10 5060 sip.provider.com run the routing algorithm on "sip.provider.com" instead of "customer.domain". Another option is to store some AS-equivalent in the customer domain and have the routing algorithm operate on that. In my domain-policy framework this could be expressed e.g. like customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id" "!.*!urn:ietf:speermint:RID:1042!" . stating that this domain can be reached using the Speermint routing logic by using the learned route to RoutingID 1042. Or, even better, use non-terminals, and thus refer to the ingress policy stored in the provider's domain: customers.domain IN NAPTR "" 10 10 "D2P+SIP" "" provider.com provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id" "!.*!urn:ietf:speermint:RID:1042!" . (+ whatever other facts provider.com wants to announce about his reachability.) This combination of our ideas can indeed work and scale to an unlimited number of customer-owned domains. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat May 27 05:04:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjuin-0003oU-9L; Sat, 27 May 2006 05:04:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjuim-0003oP-4m for speermint@ietf.org; Sat, 27 May 2006 05:04:32 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjuil-0003sL-J7 for speermint@ietf.org; Sat, 27 May 2006 05:04:32 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 27 May 2006 02:04:31 -0700 X-IronPort-AV: i="4.05,179,1146466800"; d="scan'208"; a="553961688:sNHT36702788" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Sat, 27 May 2006 05:04:28 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804652E6B@proton.jnpr.net> In-Reply-To: <20060527082920.GI1811@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2w From: "Reinaldo Penno" To: "Otmar Lendl" , "Patrick Melampy" X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: "Khan, Sohel Q \[CTO\]" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hello, I believe the crux of the problem was missed. The issue is not really the number of domains. We have today some 400.000.000 million hosts on the Internet. BGP peers to do not exchange 400.000.000 million routes, they exchange in the low hundreds of thousands. And why is that? (I guess you know where I'm getting at). That's because IP addresses lend themselves very well to hierarchical deployment, compression through prefix/CIDR usage and the like. DNS names are strings and hence difficult to come up with a similar scheme.=20 I believe that if domains need to be exchanged between peers: 1 - Just a limited set would be exchanged and a "default layer 5 route" (equivalent to a traditional default route) would be used. 2 - Compression schemes like *.company.com, regular expressions or the like would need to be used. Having specific routes to AORs would be hairy (maybe for the eventual roaming or visiting user). I wonder how LNP is solved within wireless...A specific entry for each phone? That would be crazy. 3 - Some new scheme that will make somebody rich....until then.. I believe subscriptions would be used to exchange mostly "cost" and policy information and some domains. I use cost here in the layer 3 sense (number of calls, jitter, whatever). Cost would be an abstract value or a more specific one (up to the administrator). =20 Regards, Reinaldo > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Saturday, May 27, 2006 1:29 AM > To: Patrick Melampy > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > On 2006/05/26 18:05, Patrick Melampy wrote: > > I suppose like in any distributed routing protocol, there are some > chicken > > an egg issues. But consider the following. > > > > PREREQUISITES: > > 1.) You know the destination DOMAIN from either ENUM or other means. >=20 > [...] > > > > This technique is very similar to TRIP, only its for DOMAINS and not > partial > > E.164 numbers. >=20 > [...] >=20 > > Obviously, the data set could get large, as the list of domains can be > > really big. There are some possibilities here... >=20 > Let's do a quick estimate on the number of domains involved: >=20 > Right now, operators usually give customers URIs of the form > @. As long as this is the state of affairs, > we're fine as the number of providers is quite finite (a few > thousands, perhaps). >=20 > This is like the state of affairs with respect to email, anno 1990. > Back then customers started to notice that if they use their own domain > for email, then they can switch providers without having to change > their email address. Thus a *lot* of people opted to use their > own domain for email. >=20 > My guess is that the same will happen to SIP. Once customers print > their SIP uris on business cards, they will want to use their own > domains. If providers won't support that feature then I suspect that > the regulators will step in and mandate an URI portability solution > just as they did in the PSTN with respect to numbers from number blocks. > (This could get really nasty protocol-wise, so I guess using customer- > owned domains is the far better and likelier solution to the porting > question.) >=20 > So: Anything we come up with here in SPEERMINT needs to cope with a > scenario where the use of customer domains in SIP URIs is just as > widespread as it is for email. >=20 > How many domains are used for email? That's hard to say. There are > about 60 million gTLD domains and probably more than 20 ccTLD ones. > Assuming that only a tenth of that is used for email we're at > 8 million domains. Given the exponential growth any system which > doesn't scale to at least 10 million domains will be obsolete before > the ink is dry on the RFC. >=20 > So what happens if we do some sort of BGP or TRIP with domains? >=20 > Let's say we need at least 100 bytes of state information per domain. > That makes a full routing table 1 GB worth of data. That also means > that a new border element needs to exchange that amount of data > with its peers before it has learned the current state of the > routing table. >=20 > That is some serious amount of data. >=20 > > 1.) Have notification point to a published document, and the document > lists > > all of the relevant reachability in real time. Thus any change to the > > document would generate a NOTIFICATION. >=20 > + a download of up to 1 GB per peer. >=20 > > 2.) User partial domains, broken up by the "dots". This may allow some > > wildcarding to reduce the number of domains. For instance, a carrier > like > > Verizon may have many 100's of domains attached to it, and version is > > willing to route and manage SIP traffic to any of them. The NOTIFY could > > contain something like: Verizon.com or *.verizon.com to indicate that > any > > domain in Verizon is reachable. >=20 > That's helpful if a provider uses subdomains for internal purposes, > but that won't help you with customer owned domains. >=20 > > This technique may work -- and fit nicely into an existing protocol. All > we > > would need to do is define the data models (XML?) and or documents for > > exchanging. >=20 > I think this technique can work -- if you add an aggregation step > before the routing scheme. >=20 > Take another look at BGP: there you have the concept of an > Autonomous System and not only that of prefixes. Maybe you need > something similar. >=20 > One approach to cope with hosted SIP domains could be to use the > hostnames as found in SRV records. E.g. for settings like >=20 > _sip._tcp.customer.domain IN SRV 10 10 5060 sip.provider.com >=20 > run the routing algorithm on "sip.provider.com" instead > of "customer.domain". >=20 > Another option is to store some AS-equivalent in the customer domain > and have the routing algorithm operate on that. In my domain-policy > framework this could be expressed e.g. like >=20 > customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id" > "!.*!urn:ietf:speermint:RID:1042!" . >=20 > stating that this domain can be reached using the Speermint routing > logic by using the learned route to RoutingID 1042. >=20 > Or, even better, use non-terminals, and thus refer to the ingress > policy stored in the provider's domain: >=20 > customers.domain IN NAPTR "" 10 10 "D2P+SIP" "" provider.com >=20 > provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id" > "!.*!urn:ietf:speermint:RID:1042!" . >=20 > (+ whatever other facts provider.com wants to announce about his > reachability.) >=20 > This combination of our ideas can indeed work and scale to an > unlimited number of customer-owned domains. >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat May 27 05:51:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjvSD-0003TI-LL; Sat, 27 May 2006 05:51:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjvSC-0003TD-8y for speermint@ietf.org; Sat, 27 May 2006 05:51:28 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjvS9-0007gV-Qx for speermint@ietf.org; Sat, 27 May 2006 05:51:28 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 949C31A385; Sat, 27 May 2006 11:51:24 +0200 (CEST) Date: Sat, 27 May 2006 11:51:24 +0200 From: Otmar Lendl To: Reinaldo Penno Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Message-ID: <20060527095124.GJ1811@nic.at> Mail-Followup-To: Otmar Lendl , Reinaldo Penno , Patrick Melampy , "Khan, Sohel Q [CTO]" , speermint@ietf.org References: <20060527082920.GI1811@nic.at> <9BD5D7887235424FA97DFC223CAE3C2804652E6B@proton.jnpr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2804652E6B@proton.jnpr.net> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: "Khan, Sohel Q \[CTO\]" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/05/27 11:05, Reinaldo Penno wrote: > > I believe the crux of the problem was missed. > > The issue is not really the number of domains. We have today some > 400.000.000 million hosts on the Internet. BGP peers to do not exchange > 400.000.000 million routes, they exchange in the low hundreds of > thousands. > > And why is that? (I guess you know where I'm getting at). That's because > IP addresses lend themselves very well to hierarchical deployment, > compression through prefix/CIDR usage and the like. DNS names are > strings and hence difficult to come up with a similar scheme. That's because IP-addresses, are, eh, addresses. Routing information. They are (ignoring PI space / multihoming for the moment) provider- dependent and if you change provider you will also get new IP-addresses. Domains are NAMES. Not addresses. You usually own your domain and take it with you if you switch email provider or web-hoster. Domains itself contain NO ROUTING INFORMATION. Their hierarchical structure reflects the delegation chain but in no way L3 or application layer routing. I can host the webspace of my lendl.priv.at domain anywhere in the world, using any provider that sells webspace. The .at is no guarantee at all that the webserver is located in Austria. The DNS is used to map Domain NAMES to ADDRESSES which contain routing information. Any routing schema which operates on names is per definition not suitable for aggregation, because names are independent of network topology. > I believe that if domains need to be exchanged between peers: > > 1 - Just a limited set would be exchanged and a "default layer 5 route" > (equivalent to a traditional default route) would be used. This leads to suboptimal routing (e.g. consider nic.at calling vienna.ibm.com) and doesn't absolve the core networks from running a full routing table. > 2 - Compression schemes like *.company.com, regular expressions or the > like would need to be used. Having specific routes to AORs would be > hairy (maybe for the eventual roaming or visiting user). I wonder how > LNP is solved within wireless...A specific entry for each phone? That > would be crazy. I guess the Richards on this list can give you some details on that. But from all I know most LNP solutions require the exchange of at least one routing record per ported number. (Other solutions do onward routing, there the call traverses through the donor network. Yuck.) /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat May 27 07:24:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjwuM-0005TO-JG; Sat, 27 May 2006 07:24:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjwuL-0005TH-Hi for speermint@ietf.org; Sat, 27 May 2006 07:24:37 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FjwuK-00015T-Pi for speermint@ietf.org; Sat, 27 May 2006 07:24:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Sat, 27 May 2006 13:26:23 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A80@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pI= From: "Stastny Richard" To: "Reinaldo Penno" , "Otmar Lendl" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org >I wonder how >LNP is solved within wireless...A specific entry for each phone? That >would be crazy. Ahem, ENUM? I thought that is all what ENUM is about? Richard ________________________________ Von: Reinaldo Penno [mailto:rpenno@juniper.net] Gesendet: Sa 27.05.2006 11:04 An: Otmar Lendl; Patrick Melampy Cc: Khan, Sohel Q [CTO]; speermint@ietf.org Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Hello, I believe the crux of the problem was missed. The issue is not really the number of domains. We have today some 400.000.000 million hosts on the Internet. BGP peers to do not exchange 400.000.000 million routes, they exchange in the low hundreds of thousands. And why is that? (I guess you know where I'm getting at). That's because IP addresses lend themselves very well to hierarchical deployment, compression through prefix/CIDR usage and the like. DNS names are strings and hence difficult to come up with a similar scheme. I believe that if domains need to be exchanged between peers: 1 - Just a limited set would be exchanged and a "default layer 5 route" (equivalent to a traditional default route) would be used. 2 - Compression schemes like *.company.com, regular expressions or the like would need to be used. Having specific routes to AORs would be hairy (maybe for the eventual roaming or visiting user). I wonder how LNP is solved within wireless...A specific entry for each phone? That would be crazy. 3 - Some new scheme that will make somebody rich....until then.. I believe subscriptions would be used to exchange mostly "cost" and policy information and some domains. I use cost here in the layer 3 sense (number of calls, jitter, whatever). Cost would be an abstract value or a more specific one (up to the administrator). Regards, Reinaldo > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Saturday, May 27, 2006 1:29 AM > To: Patrick Melampy > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > On 2006/05/26 18:05, Patrick Melampy wrote: > > I suppose like in any distributed routing protocol, there are some > chicken > > an egg issues. But consider the following. > > > > PREREQUISITES: > > 1.) You know the destination DOMAIN from either ENUM or other means. > > [...] > > > > This technique is very similar to TRIP, only its for DOMAINS and not > partial > > E.164 numbers. > > [...] > > > Obviously, the data set could get large, as the list of domains can be > > really big. There are some possibilities here... > > Let's do a quick estimate on the number of domains involved: > > Right now, operators usually give customers URIs of the form > @. As long as this is the state of affairs, > we're fine as the number of providers is quite finite (a few > thousands, perhaps). > > This is like the state of affairs with respect to email, anno 1990. > Back then customers started to notice that if they use their own domain > for email, then they can switch providers without having to change > their email address. Thus a *lot* of people opted to use their > own domain for email. > > My guess is that the same will happen to SIP. Once customers print > their SIP uris on business cards, they will want to use their own > domains. If providers won't support that feature then I suspect that > the regulators will step in and mandate an URI portability solution > just as they did in the PSTN with respect to numbers from number blocks. > (This could get really nasty protocol-wise, so I guess using customer- > owned domains is the far better and likelier solution to the porting > question.) > > So: Anything we come up with here in SPEERMINT needs to cope with a > scenario where the use of customer domains in SIP URIs is just as > widespread as it is for email. > > How many domains are used for email? That's hard to say. There are > about 60 million gTLD domains and probably more than 20 ccTLD ones. > Assuming that only a tenth of that is used for email we're at > 8 million domains. Given the exponential growth any system which > doesn't scale to at least 10 million domains will be obsolete before > the ink is dry on the RFC. > > So what happens if we do some sort of BGP or TRIP with domains? > > Let's say we need at least 100 bytes of state information per domain. > That makes a full routing table 1 GB worth of data. That also means > that a new border element needs to exchange that amount of data > with its peers before it has learned the current state of the > routing table. > > That is some serious amount of data. > > > 1.) Have notification point to a published document, and the document > lists > > all of the relevant reachability in real time. Thus any change to the > > document would generate a NOTIFICATION. > > + a download of up to 1 GB per peer. > > > 2.) User partial domains, broken up by the "dots". This may allow some > > wildcarding to reduce the number of domains. For instance, a carrier > like > > Verizon may have many 100's of domains attached to it, and version is > > willing to route and manage SIP traffic to any of them. The NOTIFY could > > contain something like: Verizon.com or *.verizon.com to indicate that > any > > domain in Verizon is reachable. > > That's helpful if a provider uses subdomains for internal purposes, > but that won't help you with customer owned domains. > > > This technique may work -- and fit nicely into an existing protocol. All > we > > would need to do is define the data models (XML?) and or documents for > > exchanging. > > I think this technique can work -- if you add an aggregation step > before the routing scheme. > > Take another look at BGP: there you have the concept of an > Autonomous System and not only that of prefixes. Maybe you need > something similar. > > One approach to cope with hosted SIP domains could be to use the > hostnames as found in SRV records. E.g. for settings like > > _sip._tcp.customer.domain IN SRV 10 10 5060 sip.provider.com > > run the routing algorithm on "sip.provider.com" instead > of "customer.domain". > > Another option is to store some AS-equivalent in the customer domain > and have the routing algorithm operate on that. In my domain-policy > framework this could be expressed e.g. like > > customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id" > "!.*!urn:ietf:speermint:RID:1042!" . > > stating that this domain can be reached using the Speermint routing > logic by using the learned route to RoutingID 1042. > > Or, even better, use non-terminals, and thus refer to the ingress > policy stored in the provider's domain: > > customers.domain IN NAPTR "" 10 10 "D2P+SIP" "" provider.com > > provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id" > "!.*!urn:ietf:speermint:RID:1042!" . > > (+ whatever other facts provider.com wants to announce about his > reachability.) > > This combination of our ideas can indeed work and scale to an > unlimited number of customer-owned domains. > > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat May 27 08:18:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjxko-000316-GD; Sat, 27 May 2006 08:18:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjxkk-0002qN-Ev for speermint@ietf.org; Sat, 27 May 2006 08:18:46 -0400 Received: from [204.209.140.176] (helo=wodka.aus-biz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjxkj-0006YH-63 for speermint@ietf.org; Sat, 27 May 2006 08:18:46 -0400 Received: from [192.168.1.103] (cpe-24-95-54-117.columbus.res.rr.com [24.95.54.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Duane Groth", Issuer "CAcert Class 3 Root" (not verified)) by wodka.aus-biz.com (Postfix) with ESMTP id DF2373338; Sat, 27 May 2006 08:18:40 -0400 (EDT) Message-ID: <4478439B.80802@e164.org> Date: Sat, 27 May 2006 08:18:35 -0400 From: Duane User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Otmar Lendl , Reinaldo Penno , Patrick Melampy , "Khan, Sohel Q [CTO]" , speermint@ietf.org Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture References: <20060527082920.GI1811@nic.at> <9BD5D7887235424FA97DFC223CAE3C2804652E6B@proton.jnpr.net> <20060527095124.GJ1811@nic.at> In-Reply-To: <20060527095124.GJ1811@nic.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Otmar Lendl wrote: > Domains are NAMES. Not addresses. You usually own your domain and take > it with you if you switch email provider or web-hoster. Domains itself > contain NO ROUTING INFORMATION. Their hierarchical structure reflects > the delegation chain but in no way L3 or application layer routing. Ummm does DNS servers (like pdns which has a geo module) that return info on closest server based on your IP count? -- Best regards, Duane _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat May 27 08:57:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjyLG-0006bh-Lx; Sat, 27 May 2006 08:56:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjyLF-0006bc-5j for speermint@ietf.org; Sat, 27 May 2006 08:56:29 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjyLD-0002fB-SN for speermint@ietf.org; Sat, 27 May 2006 08:56:29 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 5F60D1A385; Sat, 27 May 2006 14:56:15 +0200 (CEST) Date: Sat, 27 May 2006 14:56:15 +0200 From: Otmar Lendl To: Duane Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Message-ID: <20060527125615.GK1811@nic.at> Mail-Followup-To: Otmar Lendl , Duane , Reinaldo Penno , Patrick Melampy , "Khan, Sohel Q [CTO]" , speermint@ietf.org References: <20060527082920.GI1811@nic.at> <9BD5D7887235424FA97DFC223CAE3C2804652E6B@proton.jnpr.net> <20060527095124.GJ1811@nic.at> <4478439B.80802@e164.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4478439B.80802@e164.org> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: "Khan, Sohel Q \[CTO\]" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/05/27 14:05, Duane wrote: > Otmar Lendl wrote: > > >Domains are NAMES. Not addresses. You usually own your domain and take > >it with you if you switch email provider or web-hoster. Domains itself > >contain NO ROUTING INFORMATION. Their hierarchical structure reflects > >the delegation chain but in no way L3 or application layer routing. > > Ummm does DNS servers (like pdns which has a geo module) that return > info on closest server based on your IP count? No, as the domain (we're talking normal gTLD or ccTLD) name itself does not contain the topology information. Only after you plug that name into a mapping protocol (in this case DNS) you get topology-relevant information. Example: www.google.com is a name. In itself it contains no information where the server is located. If I make a lookup from here in Austria, I get www.google.com is an alias for www.l.google.com. www.l.google.com has address 66.249.85.104 www.l.google.com has address 66.249.85.99 The two addresses (if we ignore IP anycasting) define where on the Internet the server is located. Asking a traceroute server in australia I get www.google.com canonical name = www.l.google.com. Name: www.l.google.com Address: 66.102.7.99 Name: www.l.google.com Address: 66.102.7.147 Name: www.l.google.com Address: 66.102.7.104 /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat May 27 15:12:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk4Co-0004zD-PE; Sat, 27 May 2006 15:12:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk4Co-0004z8-9n for speermint@ietf.org; Sat, 27 May 2006 15:12:10 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fk4Cm-000237-W0 for speermint@ietf.org; Sat, 27 May 2006 15:12:10 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 27 May 2006 12:12:09 -0700 X-IronPort-AV: i="4.05,180,1146466800"; d="scan'208"; a="554064633:sNHT32104316" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Sat, 27 May 2006 15:12:06 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804652E6C@proton.jnpr.net> In-Reply-To: <20060527095124.GJ1811@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaBcyq32yKsX+7rRDeNCtP6PNNXewATatMQ From: "Reinaldo Penno" To: "Otmar Lendl" X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: "Khan, Sohel Q \[CTO\]" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org So,=20 Let's not think everything is new or unsolvable. People tend to spin things like this in "new" WGs. Of course I understand the absence of locality in the case of DNS, but there are similar cases in IP itself (mobile IP). Also, some small ISPs own their IP addresses and take them when move to another provider.=20 Anyway, before spending much time on this we should wonder if we really care about this problem. I believe exchanging domains names in a limited fashion needs no change to the infrastructure whatsoever. I'm not sure it will be needed, but it is certainly doable when the domain names are fairly static (in terms of mobility). Regards, Reinaldo > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Saturday, May 27, 2006 2:51 AM > To: Reinaldo Penno > Cc: Patrick Melampy; Khan, Sohel Q [CTO]; speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > On 2006/05/27 11:05, Reinaldo Penno wrote: > > > > I believe the crux of the problem was missed. > > > > The issue is not really the number of domains. We have today some > > 400.000.000 million hosts on the Internet. BGP peers to do not exchange > > 400.000.000 million routes, they exchange in the low hundreds of > > thousands. > > > > And why is that? (I guess you know where I'm getting at). That's because > > IP addresses lend themselves very well to hierarchical deployment, > > compression through prefix/CIDR usage and the like. DNS names are > > strings and hence difficult to come up with a similar scheme. >=20 > That's because IP-addresses, are, eh, addresses. Routing information. > They are (ignoring PI space / multihoming for the moment) provider- > dependent and if you change provider you will also get new IP-addresses. >=20 > Domains are NAMES. Not addresses. You usually own your domain and take > it with you if you switch email provider or web-hoster. Domains itself > contain NO ROUTING INFORMATION. Their hierarchical structure reflects > the delegation chain but in no way L3 or application layer routing. >=20 > I can host the webspace of my lendl.priv.at domain anywhere in the > world, using any provider that sells webspace. The .at is no guarantee > at all that the webserver is located in Austria. >=20 > The DNS is used to map Domain NAMES to ADDRESSES which contain routing > information. >=20 > Any routing schema which operates on names is per definition not > suitable for aggregation, because names are independent of network > topology. >=20 > > I believe that if domains need to be exchanged between peers: > > > > 1 - Just a limited set would be exchanged and a "default layer 5 route" > > (equivalent to a traditional default route) would be used. >=20 > This leads to suboptimal routing (e.g. consider nic.at calling > vienna.ibm.com) and doesn't absolve the core networks from running a > full routing table. >=20 > > 2 - Compression schemes like *.company.com, regular expressions or the > > like would need to be used. Having specific routes to AORs would be > > hairy (maybe for the eventual roaming or visiting user). I wonder how > > LNP is solved within wireless...A specific entry for each phone? That > > would be crazy. >=20 > I guess the Richards on this list can give you some details on that. But > from all I know most LNP solutions require the exchange of at least one > routing record per ported number. (Other solutions do onward routing, > there the call traverses through the donor network. Yuck.) >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat May 27 15:30:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk4UT-0007cE-NE; Sat, 27 May 2006 15:30:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk4US-0007c9-6J for speermint@ietf.org; Sat, 27 May 2006 15:30:24 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fk4UR-00040R-J2 for speermint@ietf.org; Sat, 27 May 2006 15:30:24 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 27 May 2006 12:30:22 -0700 X-IronPort-AV: i="4.05,180,1146466800"; d="scan'208"; a="554067400:sNHT38568460" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Sat, 27 May 2006 15:30:22 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804652E6D@proton.jnpr.net> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4A80@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIAEEYoMA== From: "Reinaldo Penno" To: "Stastny Richard" , "Otmar Lendl" X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Enum? When I dial (650) 453 2312, what is there to resolve _inside_ the wireless network that owns this number apart from the location of the user?=20 Now, in the scenario where an external call (for example, a cingular customer calling a Verizon customer (which owns an original t-mobile number). How that works today? If you say ENUM I would stand corrected (and surprised), since LNP has been fully deployed since 2003.=20 When a user takes its number with them, I assumed this punches a whole in the telephone prefix hierarchy and a specific entry somewhere is needed.=20 Regards, Reinaldo > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Saturday, May 27, 2006 4:26 AM > To: Reinaldo Penno; Otmar Lendl > Cc: speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > >I wonder how > >LNP is solved within wireless...A specific entry for each phone? That > >would be crazy. >=20 > Ahem, ENUM? >=20 > I thought that is all what ENUM is about? >=20 > Richard >=20 >=20 > ________________________________ >=20 > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Sa 27.05.2006 11:04 > An: Otmar Lendl; Patrick Melampy > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 >=20 >=20 > Hello, >=20 > I believe the crux of the problem was missed. >=20 > The issue is not really the number of domains. We have today some > 400.000.000 million hosts on the Internet. BGP peers to do not exchange > 400.000.000 million routes, they exchange in the low hundreds of > thousands. >=20 > And why is that? (I guess you know where I'm getting at). That's because > IP addresses lend themselves very well to hierarchical deployment, > compression through prefix/CIDR usage and the like. DNS names are > strings and hence difficult to come up with a similar scheme. >=20 >=20 > I believe that if domains need to be exchanged between peers: >=20 > 1 - Just a limited set would be exchanged and a "default layer 5 route" > (equivalent to a traditional default route) would be used. >=20 > 2 - Compression schemes like *.company.com, regular expressions or the > like would need to be used. Having specific routes to AORs would be > hairy (maybe for the eventual roaming or visiting user). I wonder how > LNP is solved within wireless...A specific entry for each phone? That > would be crazy. >=20 > 3 - Some new scheme that will make somebody rich....until then.. >=20 > I believe subscriptions would be used to exchange mostly "cost" and > policy information and some domains. I use cost here in the layer 3 > sense (number of calls, jitter, whatever). Cost would be an abstract > value or a more specific one (up to the administrator). >=20 > Regards, >=20 > Reinaldo >=20 > > -----Original Message----- > > From: Otmar Lendl [mailto:lendl@nic.at] > > Sent: Saturday, May 27, 2006 1:29 AM > > To: Patrick Melampy > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > On 2006/05/26 18:05, Patrick Melampy wrote: > > > I suppose like in any distributed routing protocol, there are some > > chicken > > > an egg issues. But consider the following. > > > > > > PREREQUISITES: > > > 1.) You know the destination DOMAIN from either ENUM or other means. > > > > [...] > > > > > > This technique is very similar to TRIP, only its for DOMAINS and not > > partial > > > E.164 numbers. > > > > [...] > > > > > Obviously, the data set could get large, as the list of domains can > be > > > really big. There are some possibilities here... > > > > Let's do a quick estimate on the number of domains involved: > > > > Right now, operators usually give customers URIs of the form > > @. As long as this is the state of affairs, > > we're fine as the number of providers is quite finite (a few > > thousands, perhaps). > > > > This is like the state of affairs with respect to email, anno 1990. > > Back then customers started to notice that if they use their own > domain > > for email, then they can switch providers without having to change > > their email address. Thus a *lot* of people opted to use their > > own domain for email. > > > > My guess is that the same will happen to SIP. Once customers print > > their SIP uris on business cards, they will want to use their own > > domains. If providers won't support that feature then I suspect that > > the regulators will step in and mandate an URI portability solution > > just as they did in the PSTN with respect to numbers from number > blocks. > > (This could get really nasty protocol-wise, so I guess using customer- > > owned domains is the far better and likelier solution to the porting > > question.) > > > > So: Anything we come up with here in SPEERMINT needs to cope with a > > scenario where the use of customer domains in SIP URIs is just as > > widespread as it is for email. > > > > How many domains are used for email? That's hard to say. There are > > about 60 million gTLD domains and probably more than 20 ccTLD ones. > > Assuming that only a tenth of that is used for email we're at > > 8 million domains. Given the exponential growth any system which > > doesn't scale to at least 10 million domains will be obsolete before > > the ink is dry on the RFC. > > > > So what happens if we do some sort of BGP or TRIP with domains? > > > > Let's say we need at least 100 bytes of state information per domain. > > That makes a full routing table 1 GB worth of data. That also means > > that a new border element needs to exchange that amount of data > > with its peers before it has learned the current state of the > > routing table. > > > > That is some serious amount of data. > > > > > 1.) Have notification point to a published document, and the > document > > lists > > > all of the relevant reachability in real time. Thus any change to > the > > > document would generate a NOTIFICATION. > > > > + a download of up to 1 GB per peer. > > > > > 2.) User partial domains, broken up by the "dots". This may allow > some > > > wildcarding to reduce the number of domains. For instance, a carrier > > like > > > Verizon may have many 100's of domains attached to it, and version > is > > > willing to route and manage SIP traffic to any of them. The NOTIFY > could > > > contain something like: Verizon.com or *.verizon.com to indicate > that > > any > > > domain in Verizon is reachable. > > > > That's helpful if a provider uses subdomains for internal purposes, > > but that won't help you with customer owned domains. > > > > > This technique may work -- and fit nicely into an existing protocol. > All > > we > > > would need to do is define the data models (XML?) and or documents > for > > > exchanging. > > > > I think this technique can work -- if you add an aggregation step > > before the routing scheme. > > > > Take another look at BGP: there you have the concept of an > > Autonomous System and not only that of prefixes. Maybe you need > > something similar. > > > > One approach to cope with hosted SIP domains could be to use the > > hostnames as found in SRV records. E.g. for settings like > > > > _sip._tcp.customer.domain IN SRV 10 10 5060 sip.provider.com > > > > run the routing algorithm on "sip.provider.com" instead > > of "customer.domain". > > > > Another option is to store some AS-equivalent in the customer domain > > and have the routing algorithm operate on that. In my domain-policy > > framework this could be expressed e.g. like > > > > customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > stating that this domain can be reached using the Speermint routing > > logic by using the learned route to RoutingID 1042. > > > > Or, even better, use non-terminals, and thus refer to the ingress > > policy stored in the provider's domain: > > > > customers.domain IN NAPTR "" 10 10 "D2P+SIP" "" provider.com > > > > provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > (+ whatever other facts provider.com wants to announce about his > > reachability.) > > > > This combination of our ideas can indeed work and scale to an > > unlimited number of customer-owned domains. > > > > /ol > > -- > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat May 27 15:51:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk4os-0004Vj-7S; Sat, 27 May 2006 15:51:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk4oq-0004Oi-JB for speermint@ietf.org; Sat, 27 May 2006 15:51:28 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fk4oq-0000mQ-He for speermint@ietf.org; Sat, 27 May 2006 15:51:28 -0400 Received: from [204.209.140.176] (helo=wodka.aus-biz.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fk4ai-0001gD-F4 for speermint@ietf.org; Sat, 27 May 2006 15:36:56 -0400 Received: from [192.168.1.103] (cpe-24-95-54-117.columbus.res.rr.com [24.95.54.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Duane Groth", Issuer "CAcert Class 3 Root" (not verified)) by wodka.aus-biz.com (Postfix) with ESMTP id 9C0652CDE; Sat, 27 May 2006 15:36:50 -0400 (EDT) Message-ID: <4478AA4E.3080201@e164.org> Date: Sat, 27 May 2006 15:36:46 -0400 From: Duane User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Reinaldo Penno , speermint@ietf.org Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture References: <9BD5D7887235424FA97DFC223CAE3C2804652E6D@proton.jnpr.net> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2804652E6D@proton.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Reinaldo Penno wrote: > Enum? When I dial (650) 453 2312, what is there to resolve _inside_ the > wireless network that owns this number apart from the location of the > user? > > Now, in the scenario where an external call (for example, a cingular > customer calling a Verizon customer (which owns an original t-mobile > number). How that works today? If you say ENUM I would stand corrected > (and surprised), since LNP has been fully deployed since 2003. ENUM can quite easily handle LNP in a single root tree, but as soon as you start issuing NS records you can forget it... -- Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://e164.org - Because e164.arpa is a tax on VoIP "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat May 27 17:34:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk6QM-00010t-R5; Sat, 27 May 2006 17:34:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk6QL-00010m-EM for speermint@ietf.org; Sat, 27 May 2006 17:34:17 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fk6QI-0001l3-H4 for speermint@ietf.org; Sat, 27 May 2006 17:34:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Sat, 27 May 2006 23:38:16 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A82@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIAEEYoMAAEs7nC From: "Stastny Richard" To: "Reinaldo Penno" X-Spam-Score: 0.0 (/) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org ENUM issues should not be discussed in SPEERMINT, just some questions =20 >Enum? When I dial (650) 453 2312, what is there to resolve _inside_ the >wireless network that owns this number apart from the location of the >user? and _outside_? ENUM is about numbers like +16504532312 =20 hello, we are talking E.164 numbers in ENUM, which is international = numbers =20 >Now, in the scenario where an external call (for example, a cingular >customer calling a Verizon customer (which owns an original t-mobile >number). How that works today? If you say ENUM I would stand corrected >(and surprised), since LNP has been fully deployed since 2003. Cingular?Verizon? ... we are talking about a global solution here You are a bit US centric here,=20 there is also some 200 other nations ozt there. I have no access to the US LNP database from e.g. Austria So you want to consider US national databases only in speermint? Richard ________________________________ Von: Reinaldo Penno [mailto:rpenno@juniper.net] Gesendet: Sa 27.05.2006 21:30 An: Stastny Richard; Otmar Lendl Cc: speermint@ietf.org Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Enum? When I dial (650) 453 2312, what is there to resolve _inside_ the wireless network that owns this number apart from the location of the user? Now, in the scenario where an external call (for example, a cingular customer calling a Verizon customer (which owns an original t-mobile number). How that works today? If you say ENUM I would stand corrected (and surprised), since LNP has been fully deployed since 2003. When a user takes its number with them, I assumed this punches a whole in the telephone prefix hierarchy and a specific entry somewhere is needed. Regards, Reinaldo > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Saturday, May 27, 2006 4:26 AM > To: Reinaldo Penno; Otmar Lendl > Cc: speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > >I wonder how > >LNP is solved within wireless...A specific entry for each phone? That > >would be crazy. > > Ahem, ENUM? > > I thought that is all what ENUM is about? > > Richard > > > ________________________________ > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Sa 27.05.2006 11:04 > An: Otmar Lendl; Patrick Melampy > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > Hello, > > I believe the crux of the problem was missed. > > The issue is not really the number of domains. We have today some > 400.000.000 million hosts on the Internet. BGP peers to do not exchange > 400.000.000 million routes, they exchange in the low hundreds of > thousands. > > And why is that? (I guess you know where I'm getting at). That's because > IP addresses lend themselves very well to hierarchical deployment, > compression through prefix/CIDR usage and the like. DNS names are > strings and hence difficult to come up with a similar scheme. > > > I believe that if domains need to be exchanged between peers: > > 1 - Just a limited set would be exchanged and a "default layer 5 route" > (equivalent to a traditional default route) would be used. > > 2 - Compression schemes like *.company.com, regular expressions or the > like would need to be used. Having specific routes to AORs would be > hairy (maybe for the eventual roaming or visiting user). I wonder how > LNP is solved within wireless...A specific entry for each phone? That > would be crazy. > > 3 - Some new scheme that will make somebody rich....until then.. > > I believe subscriptions would be used to exchange mostly "cost" and > policy information and some domains. I use cost here in the layer 3 > sense (number of calls, jitter, whatever). Cost would be an abstract > value or a more specific one (up to the administrator). > > Regards, > > Reinaldo > > > -----Original Message----- > > From: Otmar Lendl [mailto:lendl@nic.at] > > Sent: Saturday, May 27, 2006 1:29 AM > > To: Patrick Melampy > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > On 2006/05/26 18:05, Patrick Melampy wrote: > > > I suppose like in any distributed routing protocol, there are some > > chicken > > > an egg issues. But consider the following. > > > > > > PREREQUISITES: > > > 1.) You know the destination DOMAIN from either ENUM or other means. > > > > [...] > > > > > > This technique is very similar to TRIP, only its for DOMAINS and not > > partial > > > E.164 numbers. > > > > [...] > > > > > Obviously, the data set could get large, as the list of domains can > be > > > really big. There are some possibilities here... > > > > Let's do a quick estimate on the number of domains involved: > > > > Right now, operators usually give customers URIs of the form > > @. As long as this is the state of affairs, > > we're fine as the number of providers is quite finite (a few > > thousands, perhaps). > > > > This is like the state of affairs with respect to email, anno 1990. > > Back then customers started to notice that if they use their own > domain > > for email, then they can switch providers without having to change > > their email address. Thus a *lot* of people opted to use their > > own domain for email. > > > > My guess is that the same will happen to SIP. Once customers print > > their SIP uris on business cards, they will want to use their own > > domains. If providers won't support that feature then I suspect that > > the regulators will step in and mandate an URI portability solution > > just as they did in the PSTN with respect to numbers from number > blocks. > > (This could get really nasty protocol-wise, so I guess using customer- > > owned domains is the far better and likelier solution to the porting > > question.) > > > > So: Anything we come up with here in SPEERMINT needs to cope with a > > scenario where the use of customer domains in SIP URIs is just as > > widespread as it is for email. > > > > How many domains are used for email? That's hard to say. There are > > about 60 million gTLD domains and probably more than 20 ccTLD ones. > > Assuming that only a tenth of that is used for email we're at > > 8 million domains. Given the exponential growth any system which > > doesn't scale to at least 10 million domains will be obsolete before > > the ink is dry on the RFC. > > > > So what happens if we do some sort of BGP or TRIP with domains? > > > > Let's say we need at least 100 bytes of state information per domain. > > That makes a full routing table 1 GB worth of data. That also means > > that a new border element needs to exchange that amount of data > > with its peers before it has learned the current state of the > > routing table. > > > > That is some serious amount of data. > > > > > 1.) Have notification point to a published document, and the > document > > lists > > > all of the relevant reachability in real time. Thus any change to > the > > > document would generate a NOTIFICATION. > > > > + a download of up to 1 GB per peer. > > > > > 2.) User partial domains, broken up by the "dots". This may allow > some > > > wildcarding to reduce the number of domains. For instance, a carrier > > like > > > Verizon may have many 100's of domains attached to it, and version > is > > > willing to route and manage SIP traffic to any of them. The NOTIFY > could > > > contain something like: Verizon.com or *.verizon.com to indicate > that > > any > > > domain in Verizon is reachable. > > > > That's helpful if a provider uses subdomains for internal purposes, > > but that won't help you with customer owned domains. > > > > > This technique may work -- and fit nicely into an existing protocol. > All > > we > > > would need to do is define the data models (XML?) and or documents > for > > > exchanging. > > > > I think this technique can work -- if you add an aggregation step > > before the routing scheme. > > > > Take another look at BGP: there you have the concept of an > > Autonomous System and not only that of prefixes. Maybe you need > > something similar. > > > > One approach to cope with hosted SIP domains could be to use the > > hostnames as found in SRV records. E.g. for settings like > > > > _sip._tcp.customer.domain IN SRV 10 10 5060 sip.provider.com > > > > run the routing algorithm on "sip.provider.com" instead > > of "customer.domain". > > > > Another option is to store some AS-equivalent in the customer domain > > and have the routing algorithm operate on that. In my domain-policy > > framework this could be expressed e.g. like > > > > customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > stating that this domain can be reached using the Speermint routing > > logic by using the learned route to RoutingID 1042. > > > > Or, even better, use non-terminals, and thus refer to the ingress > > policy stored in the provider's domain: > > > > customers.domain IN NAPTR "" 10 10 "D2P+SIP" "" provider.com > > > > provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > (+ whatever other facts provider.com wants to announce about his > > reachability.) > > > > This combination of our ideas can indeed work and scale to an > > unlimited number of customer-owned domains. > > > > /ol > > -- > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat May 27 17:46:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk6bt-00028H-BC; Sat, 27 May 2006 17:46:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk6br-00028C-VC for speermint@ietf.org; Sat, 27 May 2006 17:46:11 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fk6br-0004i8-AZ for speermint@ietf.org; Sat, 27 May 2006 17:46:11 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 27 May 2006 14:46:10 -0700 X-IronPort-AV: i="4.05,180,1146466800"; d="scan'208"; a="549762882:sNHT40886188" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Sat, 27 May 2006 17:46:06 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804652E6F@proton.jnpr.net> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4A82@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIAEEYoMAAEs7nCAACcsIA= From: "Reinaldo Penno" To: "Stastny Richard" X-Spam-Score: 0.0 (/) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Apart form your outside-of-the-us rhetoric the questions remains.=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Saturday, May 27, 2006 2:38 PM > To: Reinaldo Penno > Cc: speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > ENUM issues should not be discussed in SPEERMINT, > just some questions >=20 > >Enum? When I dial (650) 453 2312, what is there to resolve _inside_ the > >wireless network that owns this number apart from the location of the > >user? >=20 > and _outside_? > ENUM is about numbers like +16504532312 >=20 > hello, we are talking E.164 numbers in ENUM, which is international > numbers >=20 > >Now, in the scenario where an external call (for example, a cingular > >customer calling a Verizon customer (which owns an original t-mobile > >number). How that works today? If you say ENUM I would stand corrected > >(and surprised), since LNP has been fully deployed since 2003. >=20 > Cingular?Verizon? ... >=20 > we are talking about a global solution here > You are a bit US centric here, > there is also some 200 other nations ozt there. >=20 > I have no access to the US LNP database from e.g. Austria >=20 > So you want to consider US national databases only in speermint? >=20 > Richard >=20 >=20 >=20 > ________________________________ >=20 > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Sa 27.05.2006 21:30 > An: Stastny Richard; Otmar Lendl > Cc: speermint@ietf.org > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 >=20 >=20 > Enum? When I dial (650) 453 2312, what is there to resolve _inside_ the > wireless network that owns this number apart from the location of the > user? >=20 >=20 > Now, in the scenario where an external call (for example, a cingular > customer calling a Verizon customer (which owns an original t-mobile > number). How that works today? If you say ENUM I would stand corrected > (and surprised), since LNP has been fully deployed since 2003. >=20 > When a user takes its number with them, I assumed this punches a whole > in the telephone prefix hierarchy and a specific entry somewhere is > needed. >=20 > Regards, >=20 > Reinaldo >=20 >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Saturday, May 27, 2006 4:26 AM > > To: Reinaldo Penno; Otmar Lendl > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > >I wonder how > > >LNP is solved within wireless...A specific entry for each phone? That > > >would be crazy. > > > > Ahem, ENUM? > > > > I thought that is all what ENUM is about? > > > > Richard > > > > > > ________________________________ > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > Gesendet: Sa 27.05.2006 11:04 > > An: Otmar Lendl; Patrick Melampy > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > > > > > Hello, > > > > I believe the crux of the problem was missed. > > > > The issue is not really the number of domains. We have today some > > 400.000.000 million hosts on the Internet. BGP peers to do not > exchange > > 400.000.000 million routes, they exchange in the low hundreds of > > thousands. > > > > And why is that? (I guess you know where I'm getting at). That's > because > > IP addresses lend themselves very well to hierarchical deployment, > > compression through prefix/CIDR usage and the like. DNS names are > > strings and hence difficult to come up with a similar scheme. > > > > > > I believe that if domains need to be exchanged between peers: > > > > 1 - Just a limited set would be exchanged and a "default layer 5 > route" > > (equivalent to a traditional default route) would be used. > > > > 2 - Compression schemes like *.company.com, regular expressions or the > > like would need to be used. Having specific routes to AORs would be > > hairy (maybe for the eventual roaming or visiting user). I wonder how > > LNP is solved within wireless...A specific entry for each phone? That > > would be crazy. > > > > 3 - Some new scheme that will make somebody rich....until then.. > > > > I believe subscriptions would be used to exchange mostly "cost" and > > policy information and some domains. I use cost here in the layer 3 > > sense (number of calls, jitter, whatever). Cost would be an abstract > > value or a more specific one (up to the administrator). > > > > Regards, > > > > Reinaldo > > > > > -----Original Message----- > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > Sent: Saturday, May 27, 2006 1:29 AM > > > To: Patrick Melampy > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > > > > > > On 2006/05/26 18:05, Patrick Melampy > wrote: > > > > I suppose like in any distributed routing protocol, there are some > > > chicken > > > > an egg issues. But consider the following. > > > > > > > > PREREQUISITES: > > > > 1.) You know the destination DOMAIN from either ENUM or other > means. > > > > > > [...] > > > > > > > > This technique is very similar to TRIP, only its for DOMAINS and > not > > > partial > > > > E.164 numbers. > > > > > > [...] > > > > > > > Obviously, the data set could get large, as the list of domains > can > > be > > > > really big. There are some possibilities here... > > > > > > Let's do a quick estimate on the number of domains involved: > > > > > > Right now, operators usually give customers URIs of the form > > > @. As long as this is the state of affairs, > > > we're fine as the number of providers is quite finite (a few > > > thousands, perhaps). > > > > > > This is like the state of affairs with respect to email, anno 1990. > > > Back then customers started to notice that if they use their own > > domain > > > for email, then they can switch providers without having to change > > > their email address. Thus a *lot* of people opted to use their > > > own domain for email. > > > > > > My guess is that the same will happen to SIP. Once customers print > > > their SIP uris on business cards, they will want to use their own > > > domains. If providers won't support that feature then I suspect that > > > the regulators will step in and mandate an URI portability solution > > > just as they did in the PSTN with respect to numbers from number > > blocks. > > > (This could get really nasty protocol-wise, so I guess using > customer- > > > owned domains is the far better and likelier solution to the porting > > > question.) > > > > > > So: Anything we come up with here in SPEERMINT needs to cope with a > > > scenario where the use of customer domains in SIP URIs is just as > > > widespread as it is for email. > > > > > > How many domains are used for email? That's hard to say. There are > > > about 60 million gTLD domains and probably more than 20 ccTLD ones. > > > Assuming that only a tenth of that is used for email we're at > > > 8 million domains. Given the exponential growth any system which > > > doesn't scale to at least 10 million domains will be obsolete before > > > the ink is dry on the RFC. > > > > > > So what happens if we do some sort of BGP or TRIP with domains? > > > > > > Let's say we need at least 100 bytes of state information per > domain. > > > That makes a full routing table 1 GB worth of data. That also means > > > that a new border element needs to exchange that amount of data > > > with its peers before it has learned the current state of the > > > routing table. > > > > > > That is some serious amount of data. > > > > > > > 1.) Have notification point to a published document, and the > > document > > > lists > > > > all of the relevant reachability in real time. Thus any change to > > the > > > > document would generate a NOTIFICATION. > > > > > > + a download of up to 1 GB per peer. > > > > > > > 2.) User partial domains, broken up by the "dots". This may allow > > some > > > > wildcarding to reduce the number of domains. For instance, a > carrier > > > like > > > > Verizon may have many 100's of domains attached to it, and version > > is > > > > willing to route and manage SIP traffic to any of them. The NOTIFY > > could > > > > contain something like: Verizon.com or *.verizon.com to indicate > > that > > > any > > > > domain in Verizon is reachable. > > > > > > That's helpful if a provider uses subdomains for internal purposes, > > > but that won't help you with customer owned domains. > > > > > > > This technique may work -- and fit nicely into an existing > protocol. > > All > > > we > > > > would need to do is define the data models (XML?) and or documents > > for > > > > exchanging. > > > > > > I think this technique can work -- if you add an aggregation step > > > before the routing scheme. > > > > > > Take another look at BGP: there you have the concept of an > > > Autonomous System and not only that of prefixes. Maybe you need > > > something similar. > > > > > > One approach to cope with hosted SIP domains could be to use the > > > hostnames as found in SRV records. E.g. for settings like > > > > > > _sip._tcp.customer.domain IN SRV 10 10 5060 sip.provider.com > > > > > > run the routing algorithm on "sip.provider.com" instead > > > of "customer.domain". > > > > > > Another option is to store some AS-equivalent in the customer domain > > > and have the routing algorithm operate on that. In my domain-policy > > > framework this could be expressed e.g. like > > > > > > customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > stating that this domain can be reached using the Speermint routing > > > logic by using the learned route to RoutingID 1042. > > > > > > Or, even better, use non-terminals, and thus refer to the ingress > > > policy stored in the provider's domain: > > > > > > customers.domain IN NAPTR "" 10 10 "D2P+SIP" "" provider.com > > > > > > provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > (+ whatever other facts provider.com wants to announce about his > > > reachability.) > > > > > > This combination of our ideas can indeed work and scale to an > > > unlimited number of customer-owned domains. > > > > > > /ol > > > -- > > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat May 27 17:51:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk6hI-00053A-NO; Sat, 27 May 2006 17:51:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk6hH-000534-1e for speermint@ietf.org; Sat, 27 May 2006 17:51:47 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fk6hG-0005tu-31 for speermint@ietf.org; Sat, 27 May 2006 17:51:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Sat, 27 May 2006 23:55:03 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A83@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIAEEYoMAAEs7nCAACcsIAAAF4UfQ== From: "Stastny Richard" To: "Reinaldo Penno" X-Spam-Score: 0.0 (/) X-Scan-Signature: 872695ea777a517bf5717e5acc69f8be Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org What question? Richard ________________________________ Von: Reinaldo Penno [mailto:rpenno@juniper.net] Gesendet: Sa 27.05.2006 23:46 An: Stastny Richard Cc: speermint@ietf.org Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Apart form your outside-of-the-us rhetoric the questions remains. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Saturday, May 27, 2006 2:38 PM > To: Reinaldo Penno > Cc: speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > ENUM issues should not be discussed in SPEERMINT, > just some questions > > >Enum? When I dial (650) 453 2312, what is there to resolve _inside_ the > >wireless network that owns this number apart from the location of the > >user? > > and _outside_? > ENUM is about numbers like +16504532312 > > hello, we are talking E.164 numbers in ENUM, which is international > numbers > > >Now, in the scenario where an external call (for example, a cingular > >customer calling a Verizon customer (which owns an original t-mobile > >number). How that works today? If you say ENUM I would stand corrected > >(and surprised), since LNP has been fully deployed since 2003. > > Cingular?Verizon? ... > > we are talking about a global solution here > You are a bit US centric here, > there is also some 200 other nations ozt there. > > I have no access to the US LNP database from e.g. Austria > > So you want to consider US national databases only in speermint? > > Richard > > > > ________________________________ > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Sa 27.05.2006 21:30 > An: Stastny Richard; Otmar Lendl > Cc: speermint@ietf.org > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > Enum? When I dial (650) 453 2312, what is there to resolve _inside_ the > wireless network that owns this number apart from the location of the > user? > > > Now, in the scenario where an external call (for example, a cingular > customer calling a Verizon customer (which owns an original t-mobile > number). How that works today? If you say ENUM I would stand corrected > (and surprised), since LNP has been fully deployed since 2003. > > When a user takes its number with them, I assumed this punches a whole > in the telephone prefix hierarchy and a specific entry somewhere is > needed. > > Regards, > > Reinaldo > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Saturday, May 27, 2006 4:26 AM > > To: Reinaldo Penno; Otmar Lendl > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > >I wonder how > > >LNP is solved within wireless...A specific entry for each phone? That > > >would be crazy. > > > > Ahem, ENUM? > > > > I thought that is all what ENUM is about? > > > > Richard > > > > > > ________________________________ > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > Gesendet: Sa 27.05.2006 11:04 > > An: Otmar Lendl; Patrick Melampy > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > > > > > Hello, > > > > I believe the crux of the problem was missed. > > > > The issue is not really the number of domains. We have today some > > 400.000.000 million hosts on the Internet. BGP peers to do not > exchange > > 400.000.000 million routes, they exchange in the low hundreds of > > thousands. > > > > And why is that? (I guess you know where I'm getting at). That's > because > > IP addresses lend themselves very well to hierarchical deployment, > > compression through prefix/CIDR usage and the like. DNS names are > > strings and hence difficult to come up with a similar scheme. > > > > > > I believe that if domains need to be exchanged between peers: > > > > 1 - Just a limited set would be exchanged and a "default layer 5 > route" > > (equivalent to a traditional default route) would be used. > > > > 2 - Compression schemes like *.company.com, regular expressions or the > > like would need to be used. Having specific routes to AORs would be > > hairy (maybe for the eventual roaming or visiting user). I wonder how > > LNP is solved within wireless...A specific entry for each phone? That > > would be crazy. > > > > 3 - Some new scheme that will make somebody rich....until then.. > > > > I believe subscriptions would be used to exchange mostly "cost" and > > policy information and some domains. I use cost here in the layer 3 > > sense (number of calls, jitter, whatever). Cost would be an abstract > > value or a more specific one (up to the administrator). > > > > Regards, > > > > Reinaldo > > > > > -----Original Message----- > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > Sent: Saturday, May 27, 2006 1:29 AM > > > To: Patrick Melampy > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > > > > > > On 2006/05/26 18:05, Patrick Melampy > wrote: > > > > I suppose like in any distributed routing protocol, there are some > > > chicken > > > > an egg issues. But consider the following. > > > > > > > > PREREQUISITES: > > > > 1.) You know the destination DOMAIN from either ENUM or other > means. > > > > > > [...] > > > > > > > > This technique is very similar to TRIP, only its for DOMAINS and > not > > > partial > > > > E.164 numbers. > > > > > > [...] > > > > > > > Obviously, the data set could get large, as the list of domains > can > > be > > > > really big. There are some possibilities here... > > > > > > Let's do a quick estimate on the number of domains involved: > > > > > > Right now, operators usually give customers URIs of the form > > > @. As long as this is the state of affairs, > > > we're fine as the number of providers is quite finite (a few > > > thousands, perhaps). > > > > > > This is like the state of affairs with respect to email, anno 1990. > > > Back then customers started to notice that if they use their own > > domain > > > for email, then they can switch providers without having to change > > > their email address. Thus a *lot* of people opted to use their > > > own domain for email. > > > > > > My guess is that the same will happen to SIP. Once customers print > > > their SIP uris on business cards, they will want to use their own > > > domains. If providers won't support that feature then I suspect that > > > the regulators will step in and mandate an URI portability solution > > > just as they did in the PSTN with respect to numbers from number > > blocks. > > > (This could get really nasty protocol-wise, so I guess using > customer- > > > owned domains is the far better and likelier solution to the porting > > > question.) > > > > > > So: Anything we come up with here in SPEERMINT needs to cope with a > > > scenario where the use of customer domains in SIP URIs is just as > > > widespread as it is for email. > > > > > > How many domains are used for email? That's hard to say. There are > > > about 60 million gTLD domains and probably more than 20 ccTLD ones. > > > Assuming that only a tenth of that is used for email we're at > > > 8 million domains. Given the exponential growth any system which > > > doesn't scale to at least 10 million domains will be obsolete before > > > the ink is dry on the RFC. > > > > > > So what happens if we do some sort of BGP or TRIP with domains? > > > > > > Let's say we need at least 100 bytes of state information per > domain. > > > That makes a full routing table 1 GB worth of data. That also means > > > that a new border element needs to exchange that amount of data > > > with its peers before it has learned the current state of the > > > routing table. > > > > > > That is some serious amount of data. > > > > > > > 1.) Have notification point to a published document, and the > > document > > > lists > > > > all of the relevant reachability in real time. Thus any change to > > the > > > > document would generate a NOTIFICATION. > > > > > > + a download of up to 1 GB per peer. > > > > > > > 2.) User partial domains, broken up by the "dots". This may allow > > some > > > > wildcarding to reduce the number of domains. For instance, a > carrier > > > like > > > > Verizon may have many 100's of domains attached to it, and version > > is > > > > willing to route and manage SIP traffic to any of them. The NOTIFY > > could > > > > contain something like: Verizon.com or *.verizon.com to indicate > > that > > > any > > > > domain in Verizon is reachable. > > > > > > That's helpful if a provider uses subdomains for internal purposes, > > > but that won't help you with customer owned domains. > > > > > > > This technique may work -- and fit nicely into an existing > protocol. > > All > > > we > > > > would need to do is define the data models (XML?) and or documents > > for > > > > exchanging. > > > > > > I think this technique can work -- if you add an aggregation step > > > before the routing scheme. > > > > > > Take another look at BGP: there you have the concept of an > > > Autonomous System and not only that of prefixes. Maybe you need > > > something similar. > > > > > > One approach to cope with hosted SIP domains could be to use the > > > hostnames as found in SRV records. E.g. for settings like > > > > > > _sip._tcp.customer.domain IN SRV 10 10 5060 sip.provider.com > > > > > > run the routing algorithm on "sip.provider.com" instead > > > of "customer.domain". > > > > > > Another option is to store some AS-equivalent in the customer domain > > > and have the routing algorithm operate on that. In my domain-policy > > > framework this could be expressed e.g. like > > > > > > customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > stating that this domain can be reached using the Speermint routing > > > logic by using the learned route to RoutingID 1042. > > > > > > Or, even better, use non-terminals, and thus refer to the ingress > > > policy stored in the provider's domain: > > > > > > customers.domain IN NAPTR "" 10 10 "D2P+SIP" "" provider.com > > > > > > provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > (+ whatever other facts provider.com wants to announce about his > > > reachability.) > > > > > > This combination of our ideas can indeed work and scale to an > > > unlimited number of customer-owned domains. > > > > > > /ol > > > -- > > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat May 27 17:58:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk6o6-0007qa-FS; Sat, 27 May 2006 17:58:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk6o5-0007oP-Ez for speermint@ietf.org; Sat, 27 May 2006 17:58:49 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fk6o4-0006KA-Pc for speermint@ietf.org; Sat, 27 May 2006 17:58:49 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 27 May 2006 14:58:48 -0700 X-IronPort-AV: i="4.05,180,1146466800"; d="scan'208"; a="549764599:sNHT42555436" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Sat, 27 May 2006 17:58:47 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804652E70@proton.jnpr.net> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4A83@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIAEEYoMAAEs7nCAACcsIAAAF4UfQAADQ9g From: "Reinaldo Penno" To: "Stastny Richard" X-Spam-Score: 0.0 (/) X-Scan-Signature: bdfdd9dd835c9bb499f7c92933fef080 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I guess your translator to/from English must be broken.=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Saturday, May 27, 2006 2:55 PM > To: Reinaldo Penno > Cc: speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > What question? > Richard >=20 > ________________________________ >=20 > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Sa 27.05.2006 23:46 > An: Stastny Richard > Cc: speermint@ietf.org > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 >=20 >=20 > Apart form your outside-of-the-us rhetoric the questions remains. >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Saturday, May 27, 2006 2:38 PM > > To: Reinaldo Penno > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > ENUM issues should not be discussed in SPEERMINT, > > just some questions > > > > >Enum? When I dial (650) 453 2312, what is there to resolve _inside_ > the > > >wireless network that owns this number apart from the location of the > > >user? > > > > and _outside_? > > ENUM is about numbers like +16504532312 > > > > hello, we are talking E.164 numbers in ENUM, which is international > > numbers > > > > >Now, in the scenario where an external call (for example, a cingular > > >customer calling a Verizon customer (which owns an original t-mobile > > >number). How that works today? If you say ENUM I would stand > corrected > > >(and surprised), since LNP has been fully deployed since 2003. > > > > Cingular?Verizon? ... > > > > we are talking about a global solution here > > You are a bit US centric here, > > there is also some 200 other nations ozt there. > > > > I have no access to the US LNP database from e.g. Austria > > > > So you want to consider US national databases only in speermint? > > > > Richard > > > > > > > > ________________________________ > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > Gesendet: Sa 27.05.2006 21:30 > > An: Stastny Richard; Otmar Lendl > > Cc: speermint@ietf.org > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > > > > > Enum? When I dial (650) 453 2312, what is there to resolve _inside_ > the > > wireless network that owns this number apart from the location of the > > user? > > > > > > Now, in the scenario where an external call (for example, a cingular > > customer calling a Verizon customer (which owns an original t-mobile > > number). How that works today? If you say ENUM I would stand corrected > > (and surprised), since LNP has been fully deployed since 2003. > > > > When a user takes its number with them, I assumed this punches a whole > > in the telephone prefix hierarchy and a specific entry somewhere is > > needed. > > > > Regards, > > > > Reinaldo > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Saturday, May 27, 2006 4:26 AM > > > To: Reinaldo Penno; Otmar Lendl > > > Cc: speermint@ietf.org > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > > > > > > >I wonder how > > > >LNP is solved within wireless...A specific entry for each phone? > That > > > >would be crazy. > > > > > > Ahem, ENUM? > > > > > > I thought that is all what ENUM is about? > > > > > > Richard > > > > > > > > > ________________________________ > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Gesendet: Sa 27.05.2006 11:04 > > > An: Otmar Lendl; Patrick Melampy > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org > > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > > > > > > > > > > > > Hello, > > > > > > I believe the crux of the problem was missed. > > > > > > The issue is not really the number of domains. We have today some > > > 400.000.000 million hosts on the Internet. BGP peers to do not > > exchange > > > 400.000.000 million routes, they exchange in the low hundreds of > > > thousands. > > > > > > And why is that? (I guess you know where I'm getting at). That's > > because > > > IP addresses lend themselves very well to hierarchical deployment, > > > compression through prefix/CIDR usage and the like. DNS names are > > > strings and hence difficult to come up with a similar scheme. > > > > > > > > > I believe that if domains need to be exchanged between peers: > > > > > > 1 - Just a limited set would be exchanged and a "default layer 5 > > route" > > > (equivalent to a traditional default route) would be used. > > > > > > 2 - Compression schemes like *.company.com, regular expressions or > the > > > like would need to be used. Having specific routes to AORs would be > > > hairy (maybe for the eventual roaming or visiting user). I wonder > how > > > LNP is solved within wireless...A specific entry for each phone? > That > > > would be crazy. > > > > > > 3 - Some new scheme that will make somebody rich....until then.. > > > > > > I believe subscriptions would be used to exchange mostly "cost" and > > > policy information and some domains. I use cost here in the layer 3 > > > sense (number of calls, jitter, whatever). Cost would be an abstract > > > value or a more specific one (up to the administrator). > > > > > > Regards, > > > > > > Reinaldo > > > > > > > -----Original Message----- > > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > > Sent: Saturday, May 27, 2006 1:29 AM > > > > To: Patrick Melampy > > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > > Architecture > > > > > > > > On 2006/05/26 18:05, Patrick Melampy > > wrote: > > > > > I suppose like in any distributed routing protocol, there are > some > > > > chicken > > > > > an egg issues. But consider the following. > > > > > > > > > > PREREQUISITES: > > > > > 1.) You know the destination DOMAIN from either ENUM or other > > means. > > > > > > > > [...] > > > > > > > > > > This technique is very similar to TRIP, only its for DOMAINS and > > not > > > > partial > > > > > E.164 numbers. > > > > > > > > [...] > > > > > > > > > Obviously, the data set could get large, as the list of domains > > can > > > be > > > > > really big. There are some possibilities here... > > > > > > > > Let's do a quick estimate on the number of domains involved: > > > > > > > > Right now, operators usually give customers URIs of the form > > > > @. As long as this is the state of > affairs, > > > > we're fine as the number of providers is quite finite (a few > > > > thousands, perhaps). > > > > > > > > This is like the state of affairs with respect to email, anno > 1990. > > > > Back then customers started to notice that if they use their own > > > domain > > > > for email, then they can switch providers without having to change > > > > their email address. Thus a *lot* of people opted to use their > > > > own domain for email. > > > > > > > > My guess is that the same will happen to SIP. Once customers print > > > > their SIP uris on business cards, they will want to use their own > > > > domains. If providers won't support that feature then I suspect > that > > > > the regulators will step in and mandate an URI portability > solution > > > > just as they did in the PSTN with respect to numbers from number > > > blocks. > > > > (This could get really nasty protocol-wise, so I guess using > > customer- > > > > owned domains is the far better and likelier solution to the > porting > > > > question.) > > > > > > > > So: Anything we come up with here in SPEERMINT needs to cope with > a > > > > scenario where the use of customer domains in SIP URIs is just as > > > > widespread as it is for email. > > > > > > > > How many domains are used for email? That's hard to say. There are > > > > about 60 million gTLD domains and probably more than 20 ccTLD > ones. > > > > Assuming that only a tenth of that is used for email we're at > > > > 8 million domains. Given the exponential growth any system which > > > > doesn't scale to at least 10 million domains will be obsolete > before > > > > the ink is dry on the RFC. > > > > > > > > So what happens if we do some sort of BGP or TRIP with domains? > > > > > > > > Let's say we need at least 100 bytes of state information per > > domain. > > > > That makes a full routing table 1 GB worth of data. That also > means > > > > that a new border element needs to exchange that amount of data > > > > with its peers before it has learned the current state of the > > > > routing table. > > > > > > > > That is some serious amount of data. > > > > > > > > > 1.) Have notification point to a published document, and the > > > document > > > > lists > > > > > all of the relevant reachability in real time. Thus any change > to > > > the > > > > > document would generate a NOTIFICATION. > > > > > > > > + a download of up to 1 GB per peer. > > > > > > > > > 2.) User partial domains, broken up by the "dots". This may > allow > > > some > > > > > wildcarding to reduce the number of domains. For instance, a > > carrier > > > > like > > > > > Verizon may have many 100's of domains attached to it, and > version > > > is > > > > > willing to route and manage SIP traffic to any of them. The > NOTIFY > > > could > > > > > contain something like: Verizon.com or *.verizon.com to indicate > > > that > > > > any > > > > > domain in Verizon is reachable. > > > > > > > > That's helpful if a provider uses subdomains for internal > purposes, > > > > but that won't help you with customer owned domains. > > > > > > > > > This technique may work -- and fit nicely into an existing > > protocol. > > > All > > > > we > > > > > would need to do is define the data models (XML?) and or > documents > > > for > > > > > exchanging. > > > > > > > > I think this technique can work -- if you add an aggregation step > > > > before the routing scheme. > > > > > > > > Take another look at BGP: there you have the concept of an > > > > Autonomous System and not only that of prefixes. Maybe you need > > > > something similar. > > > > > > > > One approach to cope with hosted SIP domains could be to use the > > > > hostnames as found in SRV records. E.g. for settings like > > > > > > > > _sip._tcp.customer.domain IN SRV 10 10 5060 sip.provider.com > > > > > > > > run the routing algorithm on "sip.provider.com" instead > > > > of "customer.domain". > > > > > > > > Another option is to store some AS-equivalent in the customer > domain > > > > and have the routing algorithm operate on that. In my > domain-policy > > > > framework this could be expressed e.g. like > > > > > > > > customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > > > stating that this domain can be reached using the Speermint > routing > > > > logic by using the learned route to RoutingID 1042. > > > > > > > > Or, even better, use non-terminals, and thus refer to the ingress > > > > policy stored in the provider's domain: > > > > > > > > customers.domain IN NAPTR "" 10 10 "D2P+SIP" "" provider.com > > > > > > > > provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > > > (+ whatever other facts provider.com wants to announce about his > > > > reachability.) > > > > > > > > This combination of our ideas can indeed work and scale to an > > > > unlimited number of customer-owned domains. > > > > > > > > /ol > > > > -- > > > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun May 28 00:48:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkDBi-0004eZ-TN; Sun, 28 May 2006 00:47:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkDBi-0004eO-As for speermint@ietf.org; Sun, 28 May 2006 00:47:38 -0400 Received: from outbound-haw.frontbridge.com ([12.129.219.97] helo=outbound4-haw-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkDBh-00077B-Ky for speermint@ietf.org; Sun, 28 May 2006 00:47:38 -0400 Received: from outbound4-haw.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound4-haw-R.bigfish.com (Postfix) with ESMTP id 3441915E68DF; Sun, 28 May 2006 04:47:33 +0000 (UTC) Received: from mail10-lon-R.bigfish.com (unknown [192.168.51.1]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by outbound4-haw.bigfish.com (Postfix) with ESMTP id AAEE415E689F; Sun, 28 May 2006 04:47:32 +0000 (UTC) Received: from mail10-lon.bigfish.com (localhost.localdomain [127.0.0.1]) by mail10-lon-R.bigfish.com (Postfix) with ESMTP id 739FD81E7BD; Sun, 28 May 2006 04:47:31 +0000 (UTC) X-BigFish: V Received: by mail10-lon (MessageSwitch) id 114879165196929_2430; Sun, 28 May 2006 04:47:31 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail10-lon.bigfish.com (Postfix) with ESMTP id D6D2681E762; Sun, 28 May 2006 04:47:30 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id k4S4kPTq027459; Sat, 27 May 2006 23:46:45 -0500 (CDT) Received: from plswg01a.ad.sprint.com (PLSWG01A.corp.sprint.com [10.214.11.47]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k4S4kPI06793; Sat, 27 May 2006 23:46:25 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by plswg01a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 May 2006 23:45:42 -0500 Received: from 10.214.74.102 ([10.214.74.102]) by PLSWB08C.ad.sprint.com ([208.10.70.245]) with Microsoft Exchange Server HTTP-DAV ; Sun, 28 May 2006 04:45:41 +0000 MIME-Version: 1.0 From: "Khan, Sohel Q [CTO]" Message-ID: <2f5e01c68211$930d0637$664ad60a@ad.sprint.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Sat, 27 May 2006 23:48:07 -0500 thread-topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Importance: normal thread-index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIAEEYoMAAEs7nCAACcsIAAAF4UfQAOV3R4 X-MimeOLE: Produced By Microsoft Exchange V6.5 X-Priority: 3 To: "Stastny Richard" , "Reinaldo Penno" X-OriginalArrivalTime: 28 May 2006 04:45:42.0384 (UTC) FILETIME=[934AB700:01C68211] X-Spam-Score: 3.1 (+++) X-Scan-Signature: 4c358d334afcd91b425d436ca5722f22 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I think issues of mobility and number portability need to be addressed = together in SPEERMINT LF. Sohel Khan, Ph.D. Sprint-Nextel -----Original Message----- From: "Stastny Richard" To: "Reinaldo Penno" Cc: "speermint@ietf.org" Sent: 5/27/06 4:52 PM Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture What question? Richard ________________________________ Von: Reinaldo Penno [mailto:rpenno@juniper.net] Gesendet: Sa 27.05.2006 23:46 An: Stastny Richard Cc: speermint@ietf.org Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Apart form your outside-of-the-us rhetoric the questions remains. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Saturday, May 27, 2006 2:38 PM > To: Reinaldo Penno > Cc: speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > ENUM issues should not be discussed in SPEERMINT, > just some questions > > >Enum? When I dial (650) 453 2312, what is there to resolve _inside_ the > >wireless network that owns this number apart from the location of the > >user? > > and _outside_? > ENUM is about numbers like +16504532312 > > hello, we are talking E.164 numbers in ENUM, which is international > numbers > > >Now, in the scenario where an external call (for example, a cingular > >customer calling a Verizon customer (which owns an original t-mobile > >number). How that works today? If you say ENUM I would stand corrected > >(and surprised), since LNP has been fully deployed since 2003. > > Cingular?Verizon? ... > > we are talking about a global solution here > You are a bit US centric here, > there is also some 200 other nations ozt there. > > I have no access to the US LNP database from e.g. Austria > > So you want to consider US national databases only in speermint? > > Richard > > > > ________________________________ > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Sa 27.05.2006 21:30 > An: Stastny Richard; Otmar Lendl > Cc: speermint@ietf.org > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > Enum? When I dial (650) 453 2312, what is there to resolve _inside_ the > wireless network that owns this number apart from the location of the > user? > > > Now, in the scenario where an external call (for example, a cingular > customer calling a Verizon customer (which owns an original t-mobile > number). How that works today? If you say ENUM I would stand corrected > (and surprised), since LNP has been fully deployed since 2003. > > When a user takes its number with them, I assumed this punches a whole > in the telephone prefix hierarchy and a specific entry somewhere is > needed. > > Regards, > > Reinaldo > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Saturday, May 27, 2006 4:26 AM > > To: Reinaldo Penno; Otmar Lendl > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > >I wonder how > > >LNP is solved within wireless...A specific entry for each phone? That > > >would be crazy. > > > > Ahem, ENUM? > > > > I thought that is all what ENUM is about? > > > > Richard > > > > > > ________________________________ > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > Gesendet: Sa 27.05.2006 11:04 > > An: Otmar Lendl; Patrick Melampy > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > > > > > Hello, > > > > I believe the crux of the problem was missed. > > > > The issue is not really the number of domains. We have today some > > 400.000.000 million hosts on the Internet. BGP peers to do not > exchange > > 400.000.000 million routes, they exchange in the low hundreds of > > thousands. > > > > And why is that? (I guess you know where I'm getting at). That's > because > > IP addresses lend themselves very well to hierarchical deployment, > > compression through prefix/CIDR usage and the like. DNS names are > > strings and hence difficult to come up with a similar scheme. > > > > > > I believe that if domains need to be exchanged between peers: > > > > 1 - Just a limited set would be exchanged and a "default layer 5 > route" > > (equivalent to a traditional default route) would be used. > > > > 2 - Compression schemes like *.company.com, regular expressions or the > > like would need to be used. Having specific routes to AORs would be > > hairy (maybe for the eventual roaming or visiting user). I wonder how > > LNP is solved within wireless...A specific entry for each phone? That > > would be crazy. > > > > 3 - Some new scheme that will make somebody rich....until then.. > > > > I believe subscriptions would be used to exchange mostly "cost" and > > policy information and some domains. I use cost here in the layer 3 > > sense (number of calls, jitter, whatever). Cost would be an abstract > > value or a more specific one (up to the administrator). > > > > Regards, > > > > Reinaldo > > > > > -----Original Message----- > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > Sent: Saturday, May 27, 2006 1:29 AM > > > To: Patrick Melampy > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > > > > > > On 2006/05/26 18:05, Patrick Melampy > wrote: > > > > I suppose like in any distributed routing protocol, there are some > > > chicken > > > > an egg issues. But consider the following. > > > > > > > > PREREQUISITES: > > > > 1.) You know the destination DOMAIN from either ENUM or other > means. > > > > > > [...] > > > > > > > > This technique is very similar to TRIP, only its for DOMAINS and > not > > > partial > > > > E.164 numbers. > > > > > > [...] > > > > > > > Obviously, the data set could get large, as the list of domains > can > > be > > > > really big. There are some possibilities here... > > > > > > Let's do a quick estimate on the number of domains involved: > > > > > > Right now, operators usually give customers URIs of the form > > > @. As long as this is the state of affairs, > > > we're fine as the number of providers is quite finite (a few > > > thousands, perhaps). > > > > > > This is like the state of affairs with respect to email, anno 1990. > > > Back then customers started to notice that if they use their own > > domain > > > for email, then they can switch providers without having to change > > > their email address. Thus a *lot* of people opted to use their > > > own domain for email. > > > > > > My guess is that the same will happen to SIP. Once customers print > > > their SIP uris on business cards, they will want to use their own > > > domains. If providers won't support that feature then I suspect that > > > the regulators will step in and mandate an URI portability solution > > > just as they did in the PSTN with respect to numbers from number > > blocks. > > > (This could get really nasty protocol-wise, so I guess using > customer- > > > owned domains is the far better and likelier solution to the porting > > > question.) > > > > > > So: Anything we come up with here in SPEERMINT needs to cope with a > > > scenario where the use of customer domains in SIP URIs is just as > > > widespread as it is for email. > > > > > > How many domains are used for email? That's hard to say. There are > > > about 60 million gTLD domains and probably more than 20 ccTLD ones. > > > Assuming that only a tenth of that is used for email we're at > > > 8 million domains. Given the exponential growth any system which > > > doesn't scale to at least 10 million domains will be obsolete before > > > the ink is dry on the RFC. > > > > > > So what happens if we do some sort of BGP or TRIP with domains? > > > > > > Let's say we need at least 100 bytes of state information per > domain. > > > That makes a full routing table 1 GB worth of data. That also means > > > that a new border element needs to exchange that amount of data > > > with its peers before it has learned the current state of the > > > routing table. > > > > > > That is some serious amount of data. > > > > > > > 1.) Have notification point to a published document, and the > > document > > > lists > > > > all of the relevant reachability in real time. Thus any change to > > the > > > > document would generate a NOTIFICATION. > > > > > > + a download of up to 1 GB per peer. > > > > > > > 2.) User partial domains, broken up by the "dots". This may allow > > some > > > > wildcarding to reduce the number of domains. For instance, a > carrier > > > like > > > > Verizon may have many 100's of domains attached to it, and version > > is > > > > willing to route and manage SIP traffic to any of them. The NOTIFY > > could > > > > contain something like: Verizon.com or *.verizon.com to indicate > > that > > > any > > > > domain in Verizon is reachable. > > > > > > That's helpful if a provider uses subdomains for internal purposes, > > > but that won't help you with customer owned domains. > > > > > > > This technique may work -- and fit nicely into an existing > protocol. > > All > > > we > > > > would need to do is define the data models (XML?) and or documents > > for > > > > exchanging. > > > > > > I think this technique can work -- if you add an aggregation step > > > before the routing scheme. > > > > > > Take another look at BGP: there you have the concept of an > > > Autonomous System and not only that of prefixes. Maybe you need > > > something similar. > > > > > > One approach to cope with hosted SIP domains could be to use the > > > hostnames as found in SRV records. E.g. for settings like > > > > > > _sip._tcp.customer.domain IN SRV 10 10 5060 sip.provider.com > > > > > > run the routing algorithm on "sip.provider.com" instead > > > of "customer.domain". > > > > > > Another option is to store some AS-equivalent in the customer domain > > > and have the routing algorithm operate on that. In my domain-policy > > > framework this could be expressed e.g. like > > > > > > customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > stating that this domain can be reached using the Speermint routing > > > logic by using the learned route to RoutingID 1042. > > > > > > Or, even better, use non-terminals, and thus refer to the ingress > > > policy stored in the provider's domain: > > > > > > customers.domain IN NAPTR "" 10 10 "D2P+SIP" "" provider.com > > > > > > provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > (+ whatever other facts provider.com wants to announce about his > > > reachability.) > > > > > > This combination of our ideas can indeed work and scale to an > > > unlimited number of customer-owned domains. > > > > > > /ol > > > -- > > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun May 28 04:10:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkGL1-00034C-O4; Sun, 28 May 2006 04:09:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkGL0-00033y-3Z for speermint@ietf.org; Sun, 28 May 2006 04:09:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkGL0-0002O9-0n for speermint@ietf.org; Sun, 28 May 2006 04:09:26 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FkGJW-00085D-US for speermint@ietf.org; Sun, 28 May 2006 04:07:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Sun, 28 May 2006 10:07:20 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A84@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIAEEYoMAAEs7nCAACcsIAAAF4UfQAOV3R4AAcK35g= From: "Stastny Richard" To: "Khan, Sohel Q [CTO]" X-Spam-Score: -2.5 (--) X-Scan-Signature: 441f623df000f14368137198649cb083 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I do not know how often I stated here that numbering issues=20 (and therefore also NUMBER Portability issues) are out-of-scope in SPEERMINT =20 So NUMBER Portablility cannot ne addressed in SPEERMINT LF =20 Or we change the SPEERMINT charter =20 Richard ________________________________ Von: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] Gesendet: So 28.05.2006 06:48 An: Stastny Richard; Reinaldo Penno Cc: speermint@ietf.org Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture I think issues of mobility and number portability need to be addressed = together in SPEERMINT LF. Sohel Khan, Ph.D. Sprint-Nextel -----Original Message----- From: "Stastny Richard" To: "Reinaldo Penno" Cc: "speermint@ietf.org" Sent: 5/27/06 4:52 PM Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture What question? Richard ________________________________ Von: Reinaldo Penno [mailto:rpenno@juniper.net] Gesendet: Sa 27.05.2006 23:46 An: Stastny Richard Cc: speermint@ietf.org Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Apart form your outside-of-the-us rhetoric the questions remains. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Saturday, May 27, 2006 2:38 PM > To: Reinaldo Penno > Cc: speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > ENUM issues should not be discussed in SPEERMINT, > just some questions > > >Enum? When I dial (650) 453 2312, what is there to resolve _inside_ the > >wireless network that owns this number apart from the location of the > >user? > > and _outside_? > ENUM is about numbers like +16504532312 > > hello, we are talking E.164 numbers in ENUM, which is international > numbers > > >Now, in the scenario where an external call (for example, a cingular > >customer calling a Verizon customer (which owns an original t-mobile > >number). How that works today? If you say ENUM I would stand corrected > >(and surprised), since LNP has been fully deployed since 2003. > > Cingular?Verizon? ... > > we are talking about a global solution here > You are a bit US centric here, > there is also some 200 other nations ozt there. > > I have no access to the US LNP database from e.g. Austria > > So you want to consider US national databases only in speermint? > > Richard > > > > ________________________________ > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Sa 27.05.2006 21:30 > An: Stastny Richard; Otmar Lendl > Cc: speermint@ietf.org > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > Enum? When I dial (650) 453 2312, what is there to resolve _inside_ the > wireless network that owns this number apart from the location of the > user? > > > Now, in the scenario where an external call (for example, a cingular > customer calling a Verizon customer (which owns an original t-mobile > number). How that works today? If you say ENUM I would stand corrected > (and surprised), since LNP has been fully deployed since 2003. > > When a user takes its number with them, I assumed this punches a whole > in the telephone prefix hierarchy and a specific entry somewhere is > needed. > > Regards, > > Reinaldo > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Saturday, May 27, 2006 4:26 AM > > To: Reinaldo Penno; Otmar Lendl > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > >I wonder how > > >LNP is solved within wireless...A specific entry for each phone? That > > >would be crazy. > > > > Ahem, ENUM? > > > > I thought that is all what ENUM is about? > > > > Richard > > > > > > ________________________________ > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > Gesendet: Sa 27.05.2006 11:04 > > An: Otmar Lendl; Patrick Melampy > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > > > > > Hello, > > > > I believe the crux of the problem was missed. > > > > The issue is not really the number of domains. We have today some > > 400.000.000 million hosts on the Internet. BGP peers to do not > exchange > > 400.000.000 million routes, they exchange in the low hundreds of > > thousands. > > > > And why is that? (I guess you know where I'm getting at). That's > because > > IP addresses lend themselves very well to hierarchical deployment, > > compression through prefix/CIDR usage and the like. DNS names are > > strings and hence difficult to come up with a similar scheme. > > > > > > I believe that if domains need to be exchanged between peers: > > > > 1 - Just a limited set would be exchanged and a "default layer 5 > route" > > (equivalent to a traditional default route) would be used. > > > > 2 - Compression schemes like *.company.com, regular expressions or the > > like would need to be used. Having specific routes to AORs would be > > hairy (maybe for the eventual roaming or visiting user). I wonder how > > LNP is solved within wireless...A specific entry for each phone? That > > would be crazy. > > > > 3 - Some new scheme that will make somebody rich....until then.. > > > > I believe subscriptions would be used to exchange mostly "cost" and > > policy information and some domains. I use cost here in the layer 3 > > sense (number of calls, jitter, whatever). Cost would be an abstract > > value or a more specific one (up to the administrator). > > > > Regards, > > > > Reinaldo > > > > > -----Original Message----- > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > Sent: Saturday, May 27, 2006 1:29 AM > > > To: Patrick Melampy > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > > > > > > On 2006/05/26 18:05, Patrick Melampy > wrote: > > > > I suppose like in any distributed routing protocol, there are some > > > chicken > > > > an egg issues. But consider the following. > > > > > > > > PREREQUISITES: > > > > 1.) You know the destination DOMAIN from either ENUM or other > means. > > > > > > [...] > > > > > > > > This technique is very similar to TRIP, only its for DOMAINS and > not > > > partial > > > > E.164 numbers. > > > > > > [...] > > > > > > > Obviously, the data set could get large, as the list of domains > can > > be > > > > really big. There are some possibilities here... > > > > > > Let's do a quick estimate on the number of domains involved: > > > > > > Right now, operators usually give customers URIs of the form > > > @. As long as this is the state of affairs, > > > we're fine as the number of providers is quite finite (a few > > > thousands, perhaps). > > > > > > This is like the state of affairs with respect to email, anno 1990. > > > Back then customers started to notice that if they use their own > > domain > > > for email, then they can switch providers without having to change > > > their email address. Thus a *lot* of people opted to use their > > > own domain for email. > > > > > > My guess is that the same will happen to SIP. Once customers print > > > their SIP uris on business cards, they will want to use their own > > > domains. If providers won't support that feature then I suspect that > > > the regulators will step in and mandate an URI portability solution > > > just as they did in the PSTN with respect to numbers from number > > blocks. > > > (This could get really nasty protocol-wise, so I guess using > customer- > > > owned domains is the far better and likelier solution to the porting > > > question.) > > > > > > So: Anything we come up with here in SPEERMINT needs to cope with a > > > scenario where the use of customer domains in SIP URIs is just as > > > widespread as it is for email. > > > > > > How many domains are used for email? That's hard to say. There are > > > about 60 million gTLD domains and probably more than 20 ccTLD ones. > > > Assuming that only a tenth of that is used for email we're at > > > 8 million domains. Given the exponential growth any system which > > > doesn't scale to at least 10 million domains will be obsolete before > > > the ink is dry on the RFC. > > > > > > So what happens if we do some sort of BGP or TRIP with domains? > > > > > > Let's say we need at least 100 bytes of state information per > domain. > > > That makes a full routing table 1 GB worth of data. That also means > > > that a new border element needs to exchange that amount of data > > > with its peers before it has learned the current state of the > > > routing table. > > > > > > That is some serious amount of data. > > > > > > > 1.) Have notification point to a published document, and the > > document > > > lists > > > > all of the relevant reachability in real time. Thus any change to > > the > > > > document would generate a NOTIFICATION. > > > > > > + a download of up to 1 GB per peer. > > > > > > > 2.) User partial domains, broken up by the "dots". This may allow > > some > > > > wildcarding to reduce the number of domains. For instance, a > carrier > > > like > > > > Verizon may have many 100's of domains attached to it, and version > > is > > > > willing to route and manage SIP traffic to any of them. The NOTIFY > > could > > > > contain something like: Verizon.com or *.verizon.com to indicate > > that > > > any > > > > domain in Verizon is reachable. > > > > > > That's helpful if a provider uses subdomains for internal purposes, > > > but that won't help you with customer owned domains. > > > > > > > This technique may work -- and fit nicely into an existing > protocol. > > All > > > we > > > > would need to do is define the data models (XML?) and or documents > > for > > > > exchanging. > > > > > > I think this technique can work -- if you add an aggregation step > > > before the routing scheme. > > > > > > Take another look at BGP: there you have the concept of an > > > Autonomous System and not only that of prefixes. Maybe you need > > > something similar. > > > > > > One approach to cope with hosted SIP domains could be to use the > > > hostnames as found in SRV records. E.g. for settings like > > > > > > _sip._tcp.customer.domain IN SRV 10 10 5060 sip.provider.com > > > > > > run the routing algorithm on "sip.provider.com" instead > > > of "customer.domain". > > > > > > Another option is to store some AS-equivalent in the customer domain > > > and have the routing algorithm operate on that. In my domain-policy > > > framework this could be expressed e.g. like > > > > > > customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > stating that this domain can be reached using the Speermint routing > > > logic by using the learned route to RoutingID 1042. > > > > > > Or, even better, use non-terminals, and thus refer to the ingress > > > policy stored in the provider's domain: > > > > > > customers.domain IN NAPTR "" 10 10 "D2P+SIP" "" provider.com > > > > > > provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > (+ whatever other facts provider.com wants to announce about his > > > reachability.) > > > > > > This combination of our ideas can indeed work and scale to an > > > unlimited number of customer-owned domains. > > > > > > /ol > > > -- > > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun May 28 13:58:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkPWe-0007Ny-GW; Sun, 28 May 2006 13:58:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkPWd-0007Nt-Fb for speermint@ietf.org; Sun, 28 May 2006 13:58:03 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkPWc-0005c0-P6 for speermint@ietf.org; Sun, 28 May 2006 13:58:03 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-36.mclnva23.covad.net [68.165.240.36]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k4SHwHdx002996 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 28 May 2006 10:58:22 -0700 From: "Richard Shockey" To: "'Reinaldo Penno'" , "'Stastny Richard'" , "'Otmar Lendl'" Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Sun, 28 May 2006 13:57:37 -0400 Message-ID: <00e501c68280$38692f00$24f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2804652E6D@proton.jnpr.net> thread-index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIAEEYoMAAvnixg X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Here .. read the soon to be RFC. Richard is right anything that looks like number translation is a ENUM issue everything else is SPEERMINT. ############ two week WG last call on this document concluded on Feb 6, 2006. The document listed below is being proposed for Standards Track RFC. Status- Proposed Standard Title : IANA Registration for an Enumservice Containing PSTN Signaling Information Author(s) : J. Livingood, R. Shockey Filename : draft-ietf-enum-pstn-03.txt Pages : 12 Date : 2006-1-18 This document registers the Enumservice type "pstn" and subtype "tel" using the URI scheme 'tel', as well as the subtype " sip" using the URI scheme 'sip' as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice is used to facilitate the routing of telephone calls in those countries where Number Portability exists. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-pstn-03.txt -- > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Saturday, May 27, 2006 3:30 PM > To: Stastny Richard; Otmar Lendl > Cc: speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > Enum? When I dial (650) 453 2312, what is there to resolve _inside_ the > wireless network that owns this number apart from the location of the > user? > > Now, in the scenario where an external call (for example, a cingular > customer calling a Verizon customer (which owns an original t-mobile > number). How that works today? If you say ENUM I would stand corrected > (and surprised), since LNP has been fully deployed since 2003. > > When a user takes its number with them, I assumed this punches a whole > in the telephone prefix hierarchy and a specific entry somewhere is > needed. > > Regards, > > Reinaldo > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Saturday, May 27, 2006 4:26 AM > > To: Reinaldo Penno; Otmar Lendl > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > >I wonder how > > >LNP is solved within wireless...A specific entry for each phone? That > > >would be crazy. > > > > Ahem, ENUM? > > > > I thought that is all what ENUM is about? > > > > Richard > > > > > > ________________________________ > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > Gesendet: Sa 27.05.2006 11:04 > > An: Otmar Lendl; Patrick Melampy > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > > > > > Hello, > > > > I believe the crux of the problem was missed. > > > > The issue is not really the number of domains. We have today some > > 400.000.000 million hosts on the Internet. BGP peers to do not > exchange > > 400.000.000 million routes, they exchange in the low hundreds of > > thousands. > > > > And why is that? (I guess you know where I'm getting at). That's > because > > IP addresses lend themselves very well to hierarchical deployment, > > compression through prefix/CIDR usage and the like. DNS names are > > strings and hence difficult to come up with a similar scheme. > > > > > > I believe that if domains need to be exchanged between peers: > > > > 1 - Just a limited set would be exchanged and a "default layer 5 > route" > > (equivalent to a traditional default route) would be used. > > > > 2 - Compression schemes like *.company.com, regular expressions or the > > like would need to be used. Having specific routes to AORs would be > > hairy (maybe for the eventual roaming or visiting user). I wonder how > > LNP is solved within wireless...A specific entry for each phone? That > > would be crazy. > > > > 3 - Some new scheme that will make somebody rich....until then.. > > > > I believe subscriptions would be used to exchange mostly "cost" and > > policy information and some domains. I use cost here in the layer 3 > > sense (number of calls, jitter, whatever). Cost would be an abstract > > value or a more specific one (up to the administrator). > > > > Regards, > > > > Reinaldo > > > > > -----Original Message----- > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > Sent: Saturday, May 27, 2006 1:29 AM > > > To: Patrick Melampy > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > > > > > > On 2006/05/26 18:05, Patrick Melampy > wrote: > > > > I suppose like in any distributed routing protocol, there are some > > > chicken > > > > an egg issues. But consider the following. > > > > > > > > PREREQUISITES: > > > > 1.) You know the destination DOMAIN from either ENUM or other > means. > > > > > > [...] > > > > > > > > This technique is very similar to TRIP, only its for DOMAINS and > not > > > partial > > > > E.164 numbers. > > > > > > [...] > > > > > > > Obviously, the data set could get large, as the list of domains > can > > be > > > > really big. There are some possibilities here... > > > > > > Let's do a quick estimate on the number of domains involved: > > > > > > Right now, operators usually give customers URIs of the form > > > @. As long as this is the state of affairs, > > > we're fine as the number of providers is quite finite (a few > > > thousands, perhaps). > > > > > > This is like the state of affairs with respect to email, anno 1990. > > > Back then customers started to notice that if they use their own > > domain > > > for email, then they can switch providers without having to change > > > their email address. Thus a *lot* of people opted to use their > > > own domain for email. > > > > > > My guess is that the same will happen to SIP. Once customers print > > > their SIP uris on business cards, they will want to use their own > > > domains. If providers won't support that feature then I suspect that > > > the regulators will step in and mandate an URI portability solution > > > just as they did in the PSTN with respect to numbers from number > > blocks. > > > (This could get really nasty protocol-wise, so I guess using > customer- > > > owned domains is the far better and likelier solution to the porting > > > question.) > > > > > > So: Anything we come up with here in SPEERMINT needs to cope with a > > > scenario where the use of customer domains in SIP URIs is just as > > > widespread as it is for email. > > > > > > How many domains are used for email? That's hard to say. There are > > > about 60 million gTLD domains and probably more than 20 ccTLD ones. > > > Assuming that only a tenth of that is used for email we're at > > > 8 million domains. Given the exponential growth any system which > > > doesn't scale to at least 10 million domains will be obsolete before > > > the ink is dry on the RFC. > > > > > > So what happens if we do some sort of BGP or TRIP with domains? > > > > > > Let's say we need at least 100 bytes of state information per > domain. > > > That makes a full routing table 1 GB worth of data. That also means > > > that a new border element needs to exchange that amount of data > > > with its peers before it has learned the current state of the > > > routing table. > > > > > > That is some serious amount of data. > > > > > > > 1.) Have notification point to a published document, and the > > document > > > lists > > > > all of the relevant reachability in real time. Thus any change to > > the > > > > document would generate a NOTIFICATION. > > > > > > + a download of up to 1 GB per peer. > > > > > > > 2.) User partial domains, broken up by the "dots". This may allow > > some > > > > wildcarding to reduce the number of domains. For instance, a > carrier > > > like > > > > Verizon may have many 100's of domains attached to it, and version > > is > > > > willing to route and manage SIP traffic to any of them. The NOTIFY > > could > > > > contain something like: Verizon.com or *.verizon.com to indicate > > that > > > any > > > > domain in Verizon is reachable. > > > > > > That's helpful if a provider uses subdomains for internal purposes, > > > but that won't help you with customer owned domains. > > > > > > > This technique may work -- and fit nicely into an existing > protocol. > > All > > > we > > > > would need to do is define the data models (XML?) and or documents > > for > > > > exchanging. > > > > > > I think this technique can work -- if you add an aggregation step > > > before the routing scheme. > > > > > > Take another look at BGP: there you have the concept of an > > > Autonomous System and not only that of prefixes. Maybe you need > > > something similar. > > > > > > One approach to cope with hosted SIP domains could be to use the > > > hostnames as found in SRV records. E.g. for settings like > > > > > > _sip._tcp.customer.domain IN SRV 10 10 5060 sip.provider.com > > > > > > run the routing algorithm on "sip.provider.com" instead > > > of "customer.domain". > > > > > > Another option is to store some AS-equivalent in the customer domain > > > and have the routing algorithm operate on that. In my domain-policy > > > framework this could be expressed e.g. like > > > > > > customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > stating that this domain can be reached using the Speermint routing > > > logic by using the learned route to RoutingID 1042. > > > > > > Or, even better, use non-terminals, and thus refer to the ingress > > > policy stored in the provider's domain: > > > > > > customers.domain IN NAPTR "" 10 10 "D2P+SIP" "" provider.com > > > > > > provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > (+ whatever other facts provider.com wants to announce about his > > > reachability.) > > > > > > This combination of our ideas can indeed work and scale to an > > > unlimited number of customer-owned domains. > > > > > > /ol > > > -- > > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun May 28 14:04:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkPc5-0008Ql-Ec; Sun, 28 May 2006 14:03:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkPc5-0008Qg-33 for speermint@ietf.org; Sun, 28 May 2006 14:03:41 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkPc3-00069C-NG for speermint@ietf.org; Sun, 28 May 2006 14:03:41 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-36.mclnva23.covad.net [68.165.240.36]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k4SI41YP004015 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 28 May 2006 11:04:03 -0700 From: "Richard Shockey" To: "'Francois D. Menard'" , "'Otmar Lendl'" , "'Michael Hammer \(mhammer\)'" Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Sun, 28 May 2006 14:03:21 -0400 Message-ID: <00e901c68281$02d3e0f0$24f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <01d101c6812b$01412060$8b02a8c0@gestionfm> thread-index: AcaA2Le010KfVlOFQ2qE5Is0+ne8LwAUcYkAAFWHPIA= X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: "'Khan, Sohel Q \[CTO\]'" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > -----Original Message----- > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > Sent: Friday, May 26, 2006 9:15 PM > To: 'Otmar Lendl'; 'Michael Hammer (mhammer)' > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > * infrastructure ENUM will be public (if it wants to enable more than > just > national peerings). > > This is why I had the Canadian ENUM trial framework modified to hold > non-terminal NAPTRs in Tier 1B which is unlike the US enum trial > framework. Yes but many of us really dislike the use of non terminal NAPTRS since their behavior is not sufficiently documented. > > > > My thinking was that one would need to progress through a series of > > steps/functions where the bootstrap steps are very public, but the > > later steps depend on the previous step enabling it. The chicken or > > egg problem shouldn't occur for first steps. > > That's why we put the bootstrapping steps into the DNS. Any other system > SPEERMINT will come up with, e.g. some SUBSCRIBE/NOTIFY would fit in very > nicely: the domain policy the can reference this framework as the > requirement to reach the destination. > > > (I do understand your model > > where you advertise what is only reachable by a few, but then it is > > working as you intended with selective unreachability being part of > > your > > design.) > > As I see the market right now, we already have a very selective > reachability > on the SIP layer between VoIP operators. > > I can't see a way to move the state of affairs to "interconnection on SIP > basis between all commercial VoIP-operators worldwide" without either > > * building a SIP routing protocol complete with transit networks > (the BGP model) > > or > > * require the possibility of direct connections between all > operators worldwide. > Determining whether the caller from halfway around the globe > is a legitimate operator is massively difficult, thus we > end running open servers. (the email model) > > Thus I think selective reachability on SIP will stay with us for the > medium > term. They are called bi-lateral agreements. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun May 28 14:10:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkPiM-0006P3-Gx; Sun, 28 May 2006 14:10:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkPiL-0006Ox-97 for speermint@ietf.org; Sun, 28 May 2006 14:10:09 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkPiJ-0006my-TC for speermint@ietf.org; Sun, 28 May 2006 14:10:09 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-36.mclnva23.covad.net [68.165.240.36]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k4SIASpT004980 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 28 May 2006 11:10:32 -0700 From: "Richard Shockey" To: , "'Michael Hammer \(mhammer\)'" , "'Otmar Lendl'" Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Sun, 28 May 2006 14:09:56 -0400 Message-ID: <00ec01c68281$efb534a0$24f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <000b01c67f40$e3064030$2800a8c0@DSX400> thread-index: AcZ/J15wu/Ba/2sNTLCXUP/3hHYAhQAFEQbgAAESENAA0GL/UA== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: "'Khan, Sohel Q \[CTO\]'" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Yes Henry ..but whether we like or not the DNS or at least the technology of DNS is becoming the defacto number translation database of choice and as such heralds the end of SS7. Queried or cached it makes no difference. > -----Original Message----- > From: Henry Sinnreich [mailto:henry@pulver.com] > Sent: Wednesday, May 24, 2006 10:47 AM > To: 'Michael Hammer (mhammer)'; 'Otmar Lendl' > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > I believe Mike is right on track. Overloading the DNS with application > protocol information, such as detailed policies for SIP is not what the > DNS > was designed for. > > Going further down this path would make the DNS a successor of the AIN! > > Thanks, Henry _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun May 28 14:33:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkQ4p-0005Lg-3t; Sun, 28 May 2006 14:33:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkQ4o-0005LS-1a for speermint@ietf.org; Sun, 28 May 2006 14:33:22 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkQ4n-0008Tk-CP for speermint@ietf.org; Sun, 28 May 2006 14:33:22 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 28 May 2006 11:33:20 -0700 X-IronPort-AV: i="4.05,182,1146466800"; d="scan'208"; a="554280931:sNHT42875492" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Sun, 28 May 2006 14:33:08 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804652E79@proton.jnpr.net> In-Reply-To: <00e501c68280$38692f00$24f0a544@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIAEEYoMAAvnixgAAD52MA= From: "Reinaldo Penno" To: , "Stastny Richard" , "Otmar Lendl" X-Spam-Score: 0.0 (/) X-Scan-Signature: 17cf8eab1d6bbd2874a56f9e3554d91d Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Richard, It seems we are not communicating at all. Did you actually read the thread from the beginning? What this "soon to be" RFC has to do with the original discussion between Otmar and me? What is the "Richard is right" thing? Are you talking about yourself in the third person, forwarding an email or what? -Reinaldo > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Sunday, May 28, 2006 10:58 AM > To: Reinaldo Penno; 'Stastny Richard'; 'Otmar Lendl' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > Here .. read the soon to be RFC. >=20 > Richard is right anything that looks like number translation is a ENUM > issue > everything else is SPEERMINT. >=20 > ############ >=20 > two week WG last call on this document concluded on Feb 6, 2006. >=20 > The document listed below is being proposed for Standards Track RFC. >=20 > Status- Proposed Standard >=20 > Title : IANA Registration for an Enumservice Containing PSTN Signaling > Information > Author(s) : J. Livingood, R. Shockey > Filename : draft-ietf-enum-pstn-03.txt > Pages : 12 > Date : 2006-1-18 >=20 > This document registers the Enumservice type "pstn" and subtype "tel" > using the URI scheme 'tel', as well as the subtype " sip" using the > URI scheme 'sip' as per the IANA registration process defined in the > ENUM specification, RFC 3761. This Enumservice is used to facilitate > the routing of telephone calls in those countries where Number > Portability exists. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-pstn-03.txt >=20 > -- >=20 >=20 > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Saturday, May 27, 2006 3:30 PM > > To: Stastny Richard; Otmar Lendl > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > Enum? When I dial (650) 453 2312, what is there to resolve _inside_ the > > wireless network that owns this number apart from the location of the > > user? > > > > Now, in the scenario where an external call (for example, a cingular > > customer calling a Verizon customer (which owns an original t-mobile > > number). How that works today? If you say ENUM I would stand corrected > > (and surprised), since LNP has been fully deployed since 2003. > > > > When a user takes its number with them, I assumed this punches a whole > > in the telephone prefix hierarchy and a specific entry somewhere is > > needed. > > > > Regards, > > > > Reinaldo > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Saturday, May 27, 2006 4:26 AM > > > To: Reinaldo Penno; Otmar Lendl > > > Cc: speermint@ietf.org > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > > > >I wonder how > > > >LNP is solved within wireless...A specific entry for each phone? That > > > >would be crazy. > > > > > > Ahem, ENUM? > > > > > > I thought that is all what ENUM is about? > > > > > > Richard > > > > > > > > > ________________________________ > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Gesendet: Sa 27.05.2006 11:04 > > > An: Otmar Lendl; Patrick Melampy > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org > > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > > > > > > > > > Hello, > > > > > > I believe the crux of the problem was missed. > > > > > > The issue is not really the number of domains. We have today some > > > 400.000.000 million hosts on the Internet. BGP peers to do not > > exchange > > > 400.000.000 million routes, they exchange in the low hundreds of > > > thousands. > > > > > > And why is that? (I guess you know where I'm getting at). That's > > because > > > IP addresses lend themselves very well to hierarchical deployment, > > > compression through prefix/CIDR usage and the like. DNS names are > > > strings and hence difficult to come up with a similar scheme. > > > > > > > > > I believe that if domains need to be exchanged between peers: > > > > > > 1 - Just a limited set would be exchanged and a "default layer 5 > > route" > > > (equivalent to a traditional default route) would be used. > > > > > > 2 - Compression schemes like *.company.com, regular expressions or the > > > like would need to be used. Having specific routes to AORs would be > > > hairy (maybe for the eventual roaming or visiting user). I wonder how > > > LNP is solved within wireless...A specific entry for each phone? That > > > would be crazy. > > > > > > 3 - Some new scheme that will make somebody rich....until then.. > > > > > > I believe subscriptions would be used to exchange mostly "cost" and > > > policy information and some domains. I use cost here in the layer 3 > > > sense (number of calls, jitter, whatever). Cost would be an abstract > > > value or a more specific one (up to the administrator). > > > > > > Regards, > > > > > > Reinaldo > > > > > > > -----Original Message----- > > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > > Sent: Saturday, May 27, 2006 1:29 AM > > > > To: Patrick Melampy > > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > > Architecture > > > > > > > > On 2006/05/26 18:05, Patrick Melampy > > wrote: > > > > > I suppose like in any distributed routing protocol, there are some > > > > chicken > > > > > an egg issues. But consider the following. > > > > > > > > > > PREREQUISITES: > > > > > 1.) You know the destination DOMAIN from either ENUM or other > > means. > > > > > > > > [...] > > > > > > > > > > This technique is very similar to TRIP, only its for DOMAINS and > > not > > > > partial > > > > > E.164 numbers. > > > > > > > > [...] > > > > > > > > > Obviously, the data set could get large, as the list of domains > > can > > > be > > > > > really big. There are some possibilities here... > > > > > > > > Let's do a quick estimate on the number of domains involved: > > > > > > > > Right now, operators usually give customers URIs of the form > > > > @. As long as this is the state of affairs, > > > > we're fine as the number of providers is quite finite (a few > > > > thousands, perhaps). > > > > > > > > This is like the state of affairs with respect to email, anno 1990. > > > > Back then customers started to notice that if they use their own > > > domain > > > > for email, then they can switch providers without having to change > > > > their email address. Thus a *lot* of people opted to use their > > > > own domain for email. > > > > > > > > My guess is that the same will happen to SIP. Once customers print > > > > their SIP uris on business cards, they will want to use their own > > > > domains. If providers won't support that feature then I suspect that > > > > the regulators will step in and mandate an URI portability solution > > > > just as they did in the PSTN with respect to numbers from number > > > blocks. > > > > (This could get really nasty protocol-wise, so I guess using > > customer- > > > > owned domains is the far better and likelier solution to the porting > > > > question.) > > > > > > > > So: Anything we come up with here in SPEERMINT needs to cope with a > > > > scenario where the use of customer domains in SIP URIs is just as > > > > widespread as it is for email. > > > > > > > > How many domains are used for email? That's hard to say. There are > > > > about 60 million gTLD domains and probably more than 20 ccTLD ones. > > > > Assuming that only a tenth of that is used for email we're at > > > > 8 million domains. Given the exponential growth any system which > > > > doesn't scale to at least 10 million domains will be obsolete before > > > > the ink is dry on the RFC. > > > > > > > > So what happens if we do some sort of BGP or TRIP with domains? > > > > > > > > Let's say we need at least 100 bytes of state information per > > domain. > > > > That makes a full routing table 1 GB worth of data. That also means > > > > that a new border element needs to exchange that amount of data > > > > with its peers before it has learned the current state of the > > > > routing table. > > > > > > > > That is some serious amount of data. > > > > > > > > > 1.) Have notification point to a published document, and the > > > document > > > > lists > > > > > all of the relevant reachability in real time. Thus any change to > > > the > > > > > document would generate a NOTIFICATION. > > > > > > > > + a download of up to 1 GB per peer. > > > > > > > > > 2.) User partial domains, broken up by the "dots". This may allow > > > some > > > > > wildcarding to reduce the number of domains. For instance, a > > carrier > > > > like > > > > > Verizon may have many 100's of domains attached to it, and version > > > is > > > > > willing to route and manage SIP traffic to any of them. The NOTIFY > > > could > > > > > contain something like: Verizon.com or *.verizon.com to indicate > > > that > > > > any > > > > > domain in Verizon is reachable. > > > > > > > > That's helpful if a provider uses subdomains for internal purposes, > > > > but that won't help you with customer owned domains. > > > > > > > > > This technique may work -- and fit nicely into an existing > > protocol. > > > All > > > > we > > > > > would need to do is define the data models (XML?) and or documents > > > for > > > > > exchanging. > > > > > > > > I think this technique can work -- if you add an aggregation step > > > > before the routing scheme. > > > > > > > > Take another look at BGP: there you have the concept of an > > > > Autonomous System and not only that of prefixes. Maybe you need > > > > something similar. > > > > > > > > One approach to cope with hosted SIP domains could be to use the > > > > hostnames as found in SRV records. E.g. for settings like > > > > > > > > _sip._tcp.customer.domain IN SRV 10 10 5060 sip.provider.com > > > > > > > > run the routing algorithm on "sip.provider.com" instead > > > > of "customer.domain". > > > > > > > > Another option is to store some AS-equivalent in the customer domain > > > > and have the routing algorithm operate on that. In my domain-policy > > > > framework this could be expressed e.g. like > > > > > > > > customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > > > stating that this domain can be reached using the Speermint routing > > > > logic by using the learned route to RoutingID 1042. > > > > > > > > Or, even better, use non-terminals, and thus refer to the ingress > > > > policy stored in the provider's domain: > > > > > > > > customers.domain IN NAPTR "" 10 10 "D2P+SIP" "" provider.com > > > > > > > > provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > > > (+ whatever other facts provider.com wants to announce about his > > > > reachability.) > > > > > > > > This combination of our ideas can indeed work and scale to an > > > > unlimited number of customer-owned domains. > > > > > > > > /ol > > > > -- > > > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun May 28 16:30:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkRto-00084t-SI; Sun, 28 May 2006 16:30:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkRtn-0007pJ-0K for speermint@ietf.org; Sun, 28 May 2006 16:30:07 -0400 Received: from mail.ficora.fi ([194.100.96.25] helo=portti1.ficora.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkRtl-0003ZO-E9 for speermint@ietf.org; Sun, 28 May 2006 16:30:06 -0400 Received: from POSTI.laru.local ([10.1.0.10]) by portti1.ficora.fi with InterScan Messaging Security Suite; Sun, 28 May 2006 23:41:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: VS: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Sun, 28 May 2006 23:30:11 +0300 Message-ID: <07BC6C0D40216E44A34BE6701694FE8603BE265C@POSTI.laru.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIAEEYoMAAEs7nCAACcsIAAAF4UfQAOV3R4AAcK35gAGOKOow== References: <32755D354E6B65498C3BD9FD496C7D462C4A84@oefeg-s04.oefeg.loc> From: "Nieminen Klaus" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1112050155==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============1112050155== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68295.84E2CE47" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68295.84E2CE47 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi folks, =20 Richard is right. From the charter: =20 > Issues that are out of scope for SPEERMINT include:=20 > > Routing of sessions which are not signaled using SIP. In > particular, SPEERMINT is constrained to consider only those > scenarios in which call routing is signaled using the SIP > protocol and addressed by SIP or SIPS URIs. E.164 numbers and > other national or private formats may only be used as defined > within the SIP protocols, and=20 So SPEERMINT is using only SIP/SIPS URIs, not E.164 numbers, so there is = no number portability issue for SPEERMINT. =20 However, I understand that you need a mechanism to do cope with NP also = in the SIP interconnection case and that can be done using = infrastructure ENUM (in fact we are now discussing implementing one in = Finland). The right place to discuss infrastructure ENUM is the ENUM WG. =20 I do not know if this is also out of our current scope, but I would like = to discuss transferring charging/tariff information between providers in = realtime. I want to raise this question, because at least in Finland we = have been used to transferring charging information (pulse charging) in = PSTN interconnection interface. This is for example used also in value = added services that are billed by the caller's operator. And I believe that we are not only ones that see this capability = benefical. In fact it is required, if we want to enable SIP-based = interconnection also for premium rate numbers and I consider it quite = essential.=20 =20 Therefore, I want to ask that do you see that we need a mechanism to = transfer charging data in SIP interconnection interface and do we have = anything ready for that? =20 regards, =20 - Klaus - ________________________________ L=E4hett=E4j=E4: Stastny Richard [mailto:Richard.Stastny@oefeg.at] L=E4hetetty: su 28.5.2006 11:07 Vastaanottaja: Khan, Sohel Q [CTO] Kopio: speermint@ietf.org Aihe: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture I do not know how often I stated here that numbering issues (and therefore also NUMBER Portability issues) are out-of-scope in SPEERMINT So NUMBER Portablility cannot ne addressed in SPEERMINT LF Or we change the SPEERMINT charter Richard ________________________________ Von: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] Gesendet: So 28.05.2006 06:48 An: Stastny Richard; Reinaldo Penno Cc: speermint@ietf.org Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture I think issues of mobility and number portability need to be addressed = together in SPEERMINT LF. Sohel Khan, Ph.D. Sprint-Nextel ------_=_NextPart_001_01C68295.84E2CE47 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [Speermint] Updated Draft: SPEERMINT Peering = Architecture=0A= =0A= =0A=
=0A=
Hi = folks,
=0A=
 
=0A=
Richard is right. From the =0A= charter:
=0A=
 
=0A=
> Issues that are out of scope for SPEERMINT include: =
=0A=
>
=0A=
> Routing of sessions which are not signaled using = SIP. =0A= In
> particular, SPEERMINT is constrained to consider only = those
> =0A= scenarios in which call routing is signaled using the SIP
> = protocol and =0A= addressed by SIP or SIPS URIs. E.164 numbers and
> other national = or =0A= private formats may only be used as defined
> within the SIP = protocols, =0A= and
=0A=
So SPEERMINT is using = only SIP/SIPS =0A= URIs, not E.164 numbers, so there is = no number =0A= portability issue for SPEERMINT.
=0A=
 
=0A=
However, I understand that = you need a =0A= mechanism to do cope with NP also in the SIP interconnection = case and =0A= that can be done using infrastructure ENUM (in fact we are now = discussing =0A= implementing one in Finland). The right place to =0A= discuss infrastructure ENUM is the ENUM WG.
=0A=
 
=0A=
I do not know if this is also = out of our =0A= current scope, but I would like = to discuss =0A= transferring charging/tariff information between providers in realtime. =0A= I want to raise this question, = because at =0A= least in Finland we have been used to transferring charging information = (pulse =0A= charging) in PSTN interconnection interface. This is for example used = also in =0A= value added services that are billed by the caller's =0A= operator.
=0A=
And I believe that we = are not only =0A= ones that see this capability benefical. In fact it is required, if we = want to =0A= enable SIP-based interconnection also for premium rate numbers and I = consider it =0A= quite essential.
=0A=
 
=0A=
Therefore, I want to = ask that do you =0A= see that we need a mechanism to transfer charging data in SIP = interconnection =0A= interface and do we have anything ready for that?
=0A=
 
=0A=
=0A=
regards,
=0A=
 
=0A=
- Klaus -
=0A=

=0A=
=0A= L=E4hett=E4j=E4: Stastny Richard =0A= [mailto:Richard.Stastny@oefeg.at]
L=E4hetetty: su 28.5.2006 =0A= 11:07
Vastaanottaja: Khan, Sohel Q [CTO]
Kopio: =0A= speermint@ietf.org
Aihe: Re: [Speermint] Updated Draft: = SPEERMINT =0A= Peering Architecture

=0A=
=0A=

I do not know how often I stated here that numbering =0A= issues
(and therefore also NUMBER Portability issues) are = out-of-scope
in =0A= SPEERMINT

So NUMBER Portablility cannot ne addressed in SPEERMINT =0A= LF

Or we change the SPEERMINT =0A= charter

Richard

________________________________

Von= : Khan, =0A= Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com]
Gesendet: =0A= So 28.05.2006 06:48
An: Stastny Richard; Reinaldo Penno
Cc: =0A= speermint@ietf.org
Betreff: RE: [Speermint] Updated Draft: SPEERMINT = Peering =0A= Architecture



I think issues of mobility and number = portability =0A= need to be addressed together in SPEERMINT LF.

Sohel Khan, =0A= Ph.D.
Sprint-Nextel

=0A= =0A= =0A= ------_=_NextPart_001_01C68295.84E2CE47-- --===============1112050155== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============1112050155==-- From speermint-bounces@ietf.org Mon May 29 09:12:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkhXk-0006a7-Mi; Mon, 29 May 2006 09:12:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkhXj-0006a2-Se for speermint@ietf.org; Mon, 29 May 2006 09:12:23 -0400 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkhXe-0004OF-PM for speermint@ietf.org; Mon, 29 May 2006 09:12:23 -0400 Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0J010050F3CGT2@firewall.mci.com> for speermint@ietf.org; Mon, 29 May 2006 13:12:16 +0000 (GMT) Received: from dgismtp01.wcomnet.com ([127.0.0.1]) by dgismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0J010092O3CGC8@dgismtp01.mcilink.com> for speermint@ietf.org; Mon, 29 May 2006 13:12:16 +0000 (GMT) Received: from XS107V7775199 ([131.146.44.147]) by dgismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0J01005I43BHOX@dgismtp01.mcilink.com> for speermint@ietf.org; Mon, 29 May 2006 13:12:16 +0000 (GMT) Date: Mon, 29 May 2006 08:11:30 -0500 From: Tim Dwight Subject: RE: [Speermint] Location Function in SPEERMINT In-reply-to: <200605262234192.SM03788@PMelampy> To: speermint@ietf.org Message-id: <000001c68321$715a71b0$932c9283@mcilink.com> Organization: MCI MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAATumxgAG4BNwABEZoVAADQ2DIAAC1z/9AAGrFeAACZ2pfQABju7wACHfcEAAAbB9IAAK1HH6AAC9BtAAAGOAdAAAMvVgACTEanAAAMf18AAA1j4AAAEyrIAAAQ+GAAADlElAAAjeTVAAbz1VIA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 06f60f0744e48a3e4358b40a71e32d86 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: timothy.dwight@verizon.com List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I find the notion that the originating network controls selection of the "crossing point", odd. I understand that this may be expedient but other than that, why would it be desirable? Tim -----Original Message----- From: Patrick Melampy [mailto:PMelampy@acmepacket.com] Sent: Friday, May 26, 2006 9:34 PM To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'James McEachern'; speermint@ietf.org Subject: RE: [Speermint] Location Function in SPEERMINT I think SPEERMINT needs to help us locate and find adjacent proxies, and attributes about those proxies. This will enable peering to be more flexible and automatic -- as opposed to sharing lots of provisioning data and using static proxy definitions (which is the way carriers peer today). I also think that the attributes of proxies should include: Reachable domains Permitted transaction rates Permitted quantity of sessions/bandwidth This is my opinion of course -- based on extensive practice. Any subset of this type of information would be ok. Notice that I did not include any media anchor's, or other methods. I do believe that you are right, this should not be required. Also I believe that the originating network has total control over selection of the "crossing point". -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Friday, May 26, 2006 2:07 PM To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'James McEachern'; speermint@ietf.org Subject: RE: [Speermint] Location Function in SPEERMINT I think the question we want to ask in SPEERMINT is: do we care about any of this? It seems to me that the originating network, and the terminating network, will arrange their signaling through designated peering points. They can, if they want, designate media peering points by using SBCs or other mechanisms that effectively rewrite the SIP message bodies. I think that we can ignore that at the peering point, because when the call gets to the peering point, it's going to have the SDP offer in the INVITE; the media anchor has been decided. Now, in many cases, I expect that as part of its network, the originating network is going to do some kind of lookup (ENUM) that will tell it the destination network, and that could influence its choice of media anchor if it's doing things like that. The point is that I don't think SPEERMINT standardizes that behavior; it's a single element (some SIP proxy) making an internal decision, and routing the call within its network appropriately. Similarly, when the terminating network gets the call, it can make an internal decision to direct the media to some box in its network, which will show up in the answer SDP. Again, that is it's proxy making an internal routing decision. BETWEEN networks, which where we are working, I don't think we are doing any media routing beyond the normal SIP and IP packet stuff. Do I have that right? -----Original Message----- From: Patrick Melampy [mailto:PMelampy@acmepacket.com] Sent: Friday, May 26, 2006 12:23 PM To: 'Michael Hammer (mhammer)'; 'James McEachern'; speermint@ietf.org Subject: RE: [Speermint] Location Function in SPEERMINT One of the best arguments for the "composed" SBC is that if your going to need to locate the "closest media anchor", what better way than associating it with a proxy. If the requirement is to NOT manage the media, but rather let natural BGP4 style internetworking mechanisms route the media optimally, then there is no need to bother with identifying a location of a media anchor. So the real issue here in terms of requirements is: Will Carriers be able to use the autonomous system path (AS_PATH) for delivery and routing of media packets from all sources (customers and suppliers) to all sources (customers and suppliers.) Another way to say the same thing more simply, will carriers put all of the signaled media onto the public internet -- as it's the only internetwork available today. If the answer is NO, then there will need to be media anchors and NAT devices. The location of these devices will be important to the efficiency and manageability of the service offering. The signaling and routing components of the SIP network MUST be aware of the media path, as the signaling plane is establishing the media path. This awareness and state suggest that there needs to be a relationship between the signaling plane and media anchor that is understood and close. I'm going to suggest here that the location of the proxy (the nearest proxy) be a substitute for the nearest media anchor point. -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Friday, May 26, 2006 11:51 AM To: James McEachern; speermint@ietf.org Subject: RE: [Speermint] Location Function in SPEERMINT I think I have lost track of what "it" is. I don't think "it" is the ability to identify a proxy that a peer should use based on location. "It" may be the ability to identify a proxy that a peer should use based on the peer identity or affiliation (federation). "Location" has geographic baggage when perhaps selective "discovery" is really what is meant. Please correct me as I may have gotten disoriented with the different mail threads. Mike > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com] > Sent: Friday, May 26, 2006 11:16 AM > To: Michael Hammer (mhammer); speermint@ietf.org > Subject: RE: [Speermint] Location Function in SPEERMINT > > So are you saying that it should be a requirement? > > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, May 26, 2006 10:52 AM > To: McEachern, James [CAR:5N00:EXCH]; Reinaldo Penno; Stastny Richard; > timothy.dwight@verizon.com; timothy.dwight@verizon.com; Brian Rosen; > Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer; > speermint@ietf.org > Subject: RE: [Speermint] Location Function in SPEERMINT > > Distance is dead IF the proxy does not have strong ties to a media > anchor point. If there is such a media anchor point, then choosing > ones that are close to calling and called parties will aid in finding > shortest routes between parties. > > However, I am not advocating for or against such media anchors, just > simply recognizing that they may exist depending on a domain's > architecture. > > There may be other reasons that peers are directed to one proxy over > another. It is useful for the domain to designate which proxies peers > should use. > > Mike > > > > -----Original Message----- > > From: James McEachern [mailto:jmce@nortel.com] > > Sent: Friday, May 26, 2006 10:44 AM > > To: Reinaldo Penno; Stastny Richard; timothy.dwight@verizon.com; > > Michael Hammer (mhammer); timothy.dwight@verizon.com; Brian Rosen; > > Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer; > > speermint@ietf.org > > Subject: RE: [Speermint] Location Function in SPEERMINT > > > > >This tells you the SIP proxy to be contacted. It does not > > tell you if > > >this the closest Sip Proxy handling @example.com users. It > also does > > >not tell you if it is the closest proxy to the callee. > > > > Is the ability to "identify the closest proxy" a requirement for > > Speermint? Many people have pointed out that distance is > dead, or at > > least should be, so it isn't clear to me that we really care. The > > Requirements and Terminology draft doesn't explicitly say, but my > > reading of section 5.2 implies this is not a requirement. > > > > That having been said, I don't necessarily have strong views either > > way. I'd just like to be clear on whether or not it is a > requirement. > > > > Jim > > > > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Thursday, May 25, 2006 5:00 PM > > To: Stastny Richard; timothy.dwight@verizon.com; Michael Hammer > > (mhammer); timothy.dwight@verizon.com; Brian Rosen; Francois D. > > Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > > Subject: RE: [Speermint] Location Function in SPEERMINT > > > > I believe it is enough. You could refine it but I might sure of the > > benefits. Maybe this problem was already solved somewhere > and I'm not > > aware. > > > > For example, The UAs would care. > > > > >From RFC3263 > > > > ;; Priority Weight Port Target > > IN SRV 0 1 5060 server1.example.com > > IN SRV 0 2 5060 server2.example.com > > > > This tells you the SIP proxy to be contacted. It does not > tell you if > > this the closest Sip Proxy handling @example.com users. It > also does > > not tell you if it is the closest proxy to the callee. > > > > In the case of a carriers providing VoIP service to a user, if this > > provider A peers with provider B in two different > locations, which one > > to choose to send to forward the call? > > > > Regards, > > > > Reinaldo > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, May 25, 2006 1:52 PM > > > To: Reinaldo Penno; timothy.dwight@verizon.com; Michael Hammer > > (mhammer); > > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > > Sohel Q > > > [CTO]; David Meyer; speermint@ietf.org > > > Subject: Re: [Speermint] Location Function in SPEERMINT > > > > > > Reinaldo said: > > > >That's maybe one of the most important issues. This could be > > complicated > > > >by the geographically dispersed networks with several > entry points. > > > >Although this might be an interesting problem it might be > > a rathole. > > > > > > So you say RFC 3263 is not enough, something is missing? > > > e.g. the geographic location of originating and terminating > > --- what? > > > > > > -SIP proxy? who cares > > > -SBC? > > > -UA? > > > > > > So we are again dealing with SBCs, in this case the > geo-location of > > these > > > -- rats, holes ;-) > > > > > > Richard > > > > > > > > > ________________________________ > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Gesendet: Do 25.05.2006 22:37 > > > An: Stastny Richard; timothy.dwight@verizon.com; Michael Hammer > > (mhammer); > > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > > Sohel Q > > > [CTO]; David Meyer; speermint@ietf.org > > > Betreff: RE: [Speermint] Location Function in SPEERMINT > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, May 25, 2006 1:26 PM > > > > To: timothy.dwight@verizon.com; Michael Hammer (mhammer); > > > > timothy.dwight@verizon.com; Brian Rosen; Francois D. > Menard; Khan, > > > Sohel Q > > > > [CTO]; David Meyer; speermint@ietf.org > > > > Subject: [Speermint] Location Function in SPEERMINT > > > > > > > > Hi all, > > > > > > > > sorry, but I am only able to reply with a short > > statement, because I > > > am > > > > on vacation and have only limited time and bandwitdh (GPRS) > > > > > > > > First, I consider this discussion regarding Infrastructure ENUM, > > LERG > > > and > > > > LNP > > > > important, but in the wrong WG. It should be discussed > in ENUM. WG > > and > > > > not in SPEERMINT > > > > > > > > SPEERMINT is only dealing with Call Routing Data (CRD), which is > > > defined > > > > as the OUTPUT of ENUM or some other means. > > > > > > > > This implies, that the location function (LF) defined in the > > > > achitecture draft happens AFTER an ENUM query and > > therefore cannot > > > > be the part of the LF. > > > > > > > > The LF can only involve the location of the destination > "network" > > > > as defined in SPEERMINT by the use of CRD (which is > > basically a SIP > > > > URI because we are currently talking only SIP in SPEERMINT) > > > > > > > > Of course SPEERMINT needs to define what it considers > > CRD, and AoR > > > > or the ingress point of a network. > > > > > > > > BUT then SPEERMINT needs also to define how the ingress > > point of a > > > > "network" is LOCATED given a SIP AoR. > > > [[Reinaldo]] > > > > > > That's maybe one of the most important issues. This could be > > complicated > > > by the geographically dispersed networks with several > entry points. > > > Although this might be an interesting problem it might be > a rathole. > > > > > > > > > > > > > > Richard > > > > > > > > > > > > ________________________________ > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > Gesendet: Do 25.05.2006 20:17 > > > > An: 'Michael Hammer (mhammer)'; > > timothy.dwight@verizon.com; Stastny > > > > Richard; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, > > Sohel Q [CTO]'; > > > > 'David Meyer'; speermint@ietf.org > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering > Architecture - LF - > > OF > > > - SF > > > > > > > > > > > > > > > > Michael Hammer said: > > > > > > > > > Tim, > > > > > > > > > > The LERG and LNP databases are intrinsically tied to > > the operation > > > of > > > > the > > > > TDM > > > > > infrastructure. Any design that perpatuates these > systems when > > > their > > > > reason > > > > > for being (TDM) goes away is a faulty design. > > > > > > > > OK with me. I only meant to point out that right now I > > have these > > > > capabilities, so recreating them isn't a high priority. > > > > > > > > > > > > > > > > > > DNS and ENUM provides the equivalent information and > > mechanisms to > > > do > > > > what > > > > is > > > > > needed in the IP domain. As such, a design that makes > > dependencies > > > on > > > > legacy > > > > > systems is deficient. I wouldn't support such a kludge. > > > > > > > > Fine. > > > > > > > > I'm a big fan of IP-domain solutions. Specifically > Infrastructure > > > ENUM > > > > looks really handy; my point before was that it's > moreso when used > > in > > > what > > > > Richard called "option 1". The alternative ("option 2") only > > > replicates > > > > the > > > > "kludge" to which I already have access. > > > > > > > > And to be fair to Richard, he did point out (subtly) that > > the latter > > > claim > > > > is a bit myopic. There are existing means by which > VSPs can gain > > > access > > > > to > > > > number portability information relative to national > destinations. > > > They > > > > don't have such access, at least not easily and not > > universally, to > > > number > > > > portability information relative to international > > destinations. If > > > that > > > > could be provided by Infrastructure ENUM (either "option 1" or > > "option > > > 2") > > > > it would be useful and would not simply replicate existing > > > capabilities. > > > > > > > > Bottom line, both options defined by Richard, would add value. > > Option > > > 1 > > > > adds more value but is specific to destinations > > identified by E.164 > > > > numbers or URIs with imbedded E.164 numbers. Which is > > the problem > > > > closest > > to > > > > hand. > > > > > > > > > > > > > > > > > > That said, if there are backward compatibilities during the > > > transition, > > > > where > > > > > some information just happens to be known by external systems, > > such > > > as > > > > you > > > > suggest > > > > > below, I don't see that as a problem. I am just wary > > of ending up > > > with > > > > two > > > > > systems in the end when one would do. > > > > > > > > Isn't it inevitable that for some time, both will > exist? Just as > > the > > > GSTN > > > > and VoIP will coexist for some time, so will their supporting > > > > infrastructure. > > > > > > > > Don't get me wrong. I'm not saying "because I have an > SS7 -based > > > solution > > > > to LNP I don't need an IP -based solution". All I'm > > saying is that > > > when > > > > given the option of using Infrastructure ENUM to > recreate (and in > > the > > > case > > > > of international destinations, extend) the capability I already > > have, > > > and > > > > using it to do that and more, I'm inclined to prefer the latter. > > > > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > > Sent: Wednesday, May 24, 2006 6:19 PM > > > > > To: 'Stastny Richard'; timothy.dwight@verizon.com; > > > > > timothy.dwight@verizon.com; Michael Hammer (mhammer); 'Brian > > Rosen'; > > > > > 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; > > > > > speermint@ietf.org > > > > > Subject: RE: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > OF > > > > > - SF > > > > > > > > > > Richard, > > > > > > > > > > Yes I know I was mixing data and mechanism-to-access-data. > > > > > Still I believe the major point to be correct. In > many parts of > > the > > > > > world there are already mechanisms (associated with > Local Number > > > > > Portability) to determine ownership of an E.164 number, > > hence use > > of > > > > > ENUM for this purpose alone, will be unnecessary. > > > > > > > > > > To be clear, I believe that providing access via > Infrastructure > > ENUM > > > > > to LNP information may be very helpful; but only if > > Infrastructure > > > > > ENUM provides more than just this. > > > > > If an Infrastructure ENUM query can combine (a) > > determination of > > > the > > > > > entity providing service to the destination, (b) > > determination of > > > the > > > > > corresponding LRN, if one exists, and (c) mapping of > > the routable > > > > > number (either the number originally indicated, or > the LRN) to a > > > Layer > > > > > 5 "point of ingress" specified by the entity providing > > service to > > > the > > > > > destination; then Infrastructure ENUM is quite a handy > > mechanism. > > > If > > > > > all it does is (a) then I don't need it. > > > > > > > > > > But in the end this is neither here nor there. I am > > not wedded to > > > any > > > > > specific technology, I just need workable solutions to real > > business > > > > > problems. > > > > > > > > > > Tim > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Wednesday, May 24, 2006 4:38 PM > > > > > To: timothy.dwight@verizon.com; timothy.dwight@verizon.com; > > Michael > > > > > Hammer (mhammer); Brian Rosen; Francois D. Menard; > > Khan, Sohel Q > > > > > [CTO]; David Meyer; speermint@ietf.org > > > > > Subject: Re: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > OF > > > > > - SF > > > > > > > > > > Tim, > > > > > > > > > > thanx for your reply, you are raising some important issues. > > > > > Since it is already midnight here, I will reply to it > in detail > > > > > tomorrow > > > > > > > > > > I am also working on a more detailed analysis and a > draft which > > will > > > > > require even some more time. > > > > > > > > > > Just a quick one: > > > > > > > > > > >In some parts of the world the function provided by "option > > > > > 2" usage of > > > > > >Infrastructure ENUM could be achieved in other ways (e.g., > > > > > the LERG and > > > > > >NPDB in North America) so in those cases Infrastructure ENUM > > > > > might be a > > > > > >superfluous concept; but if that's the right technical > > > > > answer so be it. > > > > > > > > > > Yes and no ;-) > > > > > You are mixing up here the Registry and the ENUM DNS. > > > > > The Registry is the LERG and NPDB (or is derived > from), the ENUM > > DNS > > > > > is the equivalent on IP of the SCP in the PSTN where > > the date is > > > > > downloaded to. > > > > > > > > > > Richard > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > > Gesendet: Mi 24.05.2006 23:00 > > > > > An: Stastny Richard; timothy.dwight@verizon.com; > > 'Michael Hammer > > > > > (mhammer)'; 'Brian Rosen'; 'Francois D. Menard'; > 'Khan, Sohel Q > > > > > [CTO]'; 'David Meyer'; speermint@ietf.org > > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > OF > > > > > - SF > > > > > > > > > > > > > > > > > > > > Richard, > > > > > > > > > > Thank you for the clarification. I understand the > > distinction you > > > are > > > > > making. > > > > > > > > > > My objective is to be able to translate a destination > identifier > > > > > (E.164 number of alphanumeric AoR) into the address of > > a Layer 5 > > > > > entity designated by the organization providing service to the > > > called > > > > > party. With infrastructure/carrier ENUM I could do this (as > > > described > > > > > in your Option 1), but because ENUM is specific to > E.164 numbers > > it > > > > > would only work for E.164 -formatted destination identifiers. > > > > > > > > > > In pictures, your Option 2 seems to me to imply the following: > > > > > > > > > > +----------------+ +----------+ > > > > > E.164 | infrastructure | serving | identify > > > > > | network > > > > > ingress > > > > > destination -->| ENUM |---> carrier --->| ingress > > > > > |---> point > > > > > specified > > > > > identifier | (option 2) | identity | point | > > > by > > > > > serving carrier > > > > > +----------------+ ^ +----------+ > > > > > | > > > > > +----------------+ | > > > > > non-E.164 | map domain in | | > > > > > Destination -->| URI to carrier |--------+ > > > > > Identifier | identity | > > > > > +----------------+ > > > > > > > > > > In some parts of the world the function provided by "option 2" > > usage > > > > > of Infrastructure ENUM could be achieved in other ways > > (e.g., the > > > LERG > > > > > and NPDB in North America) so in those cases > Infrastructure ENUM > > > might > > > > > be a superfluous concept; but if that's the right > > technical answer > > > so > > > > > be it. > > > > > > > > > > The "identify ingress point" function would need to be > > defined. I > > > > > would like it to consider the specified destination > (in addition > > to > > > > > the carrier providing service to that destination); > and I would > > like > > > > > the procedures to be such that the serving carrier > > controls (in a > > > > > reasonably dynamic > > > > > way) the point at which traffic destined to a particular > > > destination, > > > > > enters his network. If those requirements can be met, I think > > this > > > > > approach is workable. > > > > > > > > > > Its biggest drawback is that it precludes a solution > ("option 1" > > > usage > > > > > of Infrastructure ENUM) that is sufficient for the majority of > > > today's > > > > > needs. > > > > > It optimizes for a problem that will exist in the > future at the > > > > > expense of solving problems that exist today. I realize that > > > solving > > > > > today's problems may not be SPEERMINT's focus, or > > (arguably) even > > > > > within its charter, but I would hate to see > > recommendations from > > > > > SPEERMINT preclude or significantly delay solving them. > > > > > > > > > > Suppose we did something like this: > > > > > > > > > > +----------+ [pseudo +----------------+ > > > > > non-E.164 | identify | or real] | infrastructure > > > > > | network > > > > > ingress > > > > > destination -->| "pseudo" |---> E.164 --->| ENUM > > > > > |---> point > > > > > specified > > > > > identifier | E.164 | number | (option 1) | > > > by > > > > > serving carrier > > > > > +----------+ +----------------+ > > > > > > > > > > We could let the ENUM working group define > > Infrastructure ENUM as > > > > > described in your Option 1 (which is as you know already > > > commercially > > > > > available from a few sources) and SPEERMINT could define the > > > "identify > > > > > pseudo E.164" function that in my diagram feeds into > it. This > > > > > function might be as simple as mapping the domain part > > of the URI > > to > > > > > an E.164 number uniquely associated with the network providing > > > service > > > > > to the specified destination. Unless this is a lot > > harder than it > > > > > seems, this shouldn't keep us busy too long :-) > > > > > > > > > > > > > > > Tim > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Wednesday, May 24, 2006 11:16 AM > > > > > To: timothy.dwight@verizon.com; Michael Hammer > (mhammer); Brian > > > > > Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer; > > > > > speermint@ietf.org > > > > > Subject: Re: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > > > OF - SF > > > > > > > > > > Tim, > > > > > > > > > > >> ... the basic idea of Infrastructure ENUM (which > will be used > > for > > > > > >> service providers is to provide a domain name in a > > SIP URI = a > > > > > >> service provider ID > > > > > >(SPID) > > > > > > > > > > >At the risk of asking an off-topic question (realizing that > > > > > ENUM is not > > > > > >within scope for SPEERMINT), can I ask where the idea that > > > > > >Infrastructure ENUM queries return SPIDs, comes from? It is > > > > > my intent > > > > > >to provide a point of interconnection to be used by the > > requesting > > > > > >entity to hand to me a call to the specified number. I do > > > > > not intend > > > > > >that the only meaningful part of the URI returned from the > > > > > ENUM query, > > > > > >be > > > > > the domain name. > > > > > > > > > > thank you for raising this important point. I tried to > > raise this > > > > > some time ago, but got no clear answer > > > > > > > > > > Currently there exist two lines of thought about the usage of > > > > > Infrastructure (and also Carrier ENUM in private trees) > > > > > > > > > > 1. Put in ENUM the ingress point(s) e.g. > > > > > sip:+43xxxx@sbc4711.provider.net 2. > > > > > Put in ENUM the AoR only: e.g. sip:+43xxx@provider.net > > > > > (provider.net is what I meant with SPID) > > > > > > > > > > Most currently prefer option 1, especially in private > > ENUM trees. > > > > > > > > > > IMHO this is the wrong approach: > > > > > > > > > > There should be a clear separation (and it is in the charter) > > > > > between ENUM and SPEERMINT SPEERMINT peering MUST be > > able to work > > > > > standalone and without ENUM. > > > > > > > > > > Option 1 assumes also that the user is entering ALWAYS an > > > > > E.164 number as identifier. > > > > > > > > > > But what if he is entering an AoR? > > > > > > > > > > SPEEMINT peering MUST be able to resolve this too so > > you need to > > > > > find the ingress point independant of ENUM e.g. via RFC3263. > > > > > > > > > > If this MUST be possible, why not enter in (any) ENUM > just the > > > > > AoR, if you must be able to resolve the AoR anyway? > > > > > > > > > > Otherwise you need to manage two mappings separate 1. the > > > > > E.164 to ingress point 2. the AoR mapping to ingress point > > > > > > > > > > this is not a good idea > > > > > > > > > > This is the reason why I would prefer to enter in ENUM > > AoRs only > > > > > the user part in ENUM is always the E.164 number (for privacy > > > > > reasons) the domain part is the SPID, which is mapped > later to > > > > > find the ingress point > > > > > > > > > > the calling user may then also use an alis AoR such as > > > > > sip:name@provider.net > > > > > > > > > > regards > > > > > > > > > > Richard > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > > Gesendet: Mi 24.05.2006 16:46 > > > > > An: Stastny Richard; 'Michael Hammer (mhammer)'; > 'Brian Rosen'; > > > > > 'Francois D. > > > > > Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; > > speermint@ietf.org > > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > > > OF - SF > > > > > > > > > > > > > > > > > > > > Stastny, Richard said: > > > > > > > > > > > ... the basic idea of Infrastructure ENUM (which > will be used > > for > > > > > > service providers is to provide a domain name in a SIP URI > > > > > = a service > > > > > > provider ID > > > > > (SPID) > > > > > > > > > > At the risk of asking an off-topic question (realizing > > that ENUM > > > > > is not within scope for SPEERMINT), can I ask where the > > idea that > > > > > Infrastructure ENUM queries return SPIDs, comes from? > It is my > > > > > intent to provide a point of interconnection to be > used by the > > > > > requesting entity to hand to me a call to the specified > > number. I > > > > > do not intend that the only meaningful part of the > URI returned > > > > > from the ENUM query, be the domain name. > > > > > > > > > > tim > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon May 29 09:48:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fki68-0003js-GO; Mon, 29 May 2006 09:47:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fki67-0003jn-DR for speermint@ietf.org; Mon, 29 May 2006 09:47:55 -0400 Received: from [205.151.208.34] (helo=fw.tr.xittelecom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fki66-0000S8-Uc for speermint@ietf.org; Mon, 29 May 2006 09:47:55 -0400 Received: from [192.168.2.139] (helo=gestionfm) by fw.tr.xittelecom.com with esmtp (Exim 3.36 #1 (Debian)) id 1FvxOJ-0004rZ-00; Thu, 29 Jun 2006 10:21:11 -0400 From: "Francois D. Menard" To: "'Nieminen Klaus'" , Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Mon, 29 May 2006 09:45:49 -0400 Message-ID: <006401c68326$350231d0$8b02a8c0@gestionfm> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIAEEYoMAAEs7nCAACcsIAAAF4UfQAOV3R4AAcK35gAGOKOowAlM1CA In-Reply-To: <07BC6C0D40216E44A34BE6701694FE8603BE265C@POSTI.laru.local> X-Spam-Score: 0.1 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0688167661==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============0688167661== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0065_01C68304.ADF091D0" This is a multi-part message in MIME format. ------=_NextPart_000_0065_01C68304.ADF091D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Klaus, =20 I've always thought we could put some Open Settlement Protocol XML data = in a SIP invite. =20 F. =20 -- Fran=E7ois D. M=E9nard Charg=E9 de projet Xit t=E9l=E9com inc. 1350 rue Royale #800 Trois-Rivi=E8res, QC, G9A 4J4 Canada fmenard@xittelecom.com Tel: (819) 374-2556 ext. 268 Fax: (819) 374-0395 Cell: (819) 692-1383 =20 =20 _____ =20 From: Nieminen Klaus [mailto:Klaus.Nieminen@ficora.fi]=20 Sent: 28 mai 2006 16:30 To: speermint@ietf.org Subject: VS: [Speermint] Updated Draft: SPEERMINT Peering Architecture Hi folks, =20 Richard is right. From the charter: =20 > Issues that are out of scope for SPEERMINT include:=20 > > Routing of sessions which are not signaled using SIP. In > particular, SPEERMINT is constrained to consider only those > scenarios in which call routing is signaled using the SIP > protocol and addressed by SIP or SIPS URIs. E.164 numbers and > other national or private formats may only be used as defined > within the SIP protocols, and=20 So SPEERMINT is using only SIP/SIPS URIs, not E.164 numbers, so there is = no number portability issue for SPEERMINT. =20 However, I understand that you need a mechanism to do cope with NP also = in the SIP interconnection case and that can be done using infrastructure = ENUM (in fact we are now discussing implementing one in Finland). The right = place to discuss infrastructure ENUM is the ENUM WG. =20 I do not know if this is also out of our current scope, but I would like = to discuss transferring charging/tariff information between providers in realtime. I want to raise this question, because at least in Finland we = have been used to transferring charging information (pulse charging) in PSTN interconnection interface. This is for example used also in value added services that are billed by the caller's operator. And I believe that we are not only ones that see this capability = benefical. In fact it is required, if we want to enable SIP-based interconnection = also for premium rate numbers and I consider it quite essential.=20 =20 Therefore, I want to ask that do you see that we need a mechanism to transfer charging data in SIP interconnection interface and do we have anything ready for that? =20 regards, =20 - Klaus - _____ =20 L=E4hett=E4j=E4: Stastny Richard [mailto:Richard.Stastny@oefeg.at] L=E4hetetty: su 28.5.2006 11:07 Vastaanottaja: Khan, Sohel Q [CTO] Kopio: speermint@ietf.org Aihe: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture I do not know how often I stated here that numbering issues (and therefore also NUMBER Portability issues) are out-of-scope in SPEERMINT So NUMBER Portablility cannot ne addressed in SPEERMINT LF Or we change the SPEERMINT charter Richard ________________________________ Von: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] Gesendet: So 28.05.2006 06:48 An: Stastny Richard; Reinaldo Penno Cc: speermint@ietf.org Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture I think issues of mobility and number portability need to be addressed together in SPEERMINT LF. Sohel Khan, Ph.D. Sprint-Nextel ------=_NextPart_000_0065_01C68304.ADF091D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Speermint] Updated Draft: SPEERMINT Peering = Architecture
Klaus,
 
I've always thought we could put some Open = Settlement=20 Protocol XML data in a SIP invite.
 
F.
 
--
Fran=E7ois D. = M=E9nard
Charg=E9 de = projet
Xit t=E9l=E9com = inc.
1350 rue Royale = #800
Trois-Rivi=E8res, QC, G9A = 4J4
Canada
fmenard@xittelecom.com<= /DIV>
Tel: (819) 374-2556 ext.=20 268
Fax: (819) = 374-0395
Cell: (819) = 692-1383
 
 

From: Nieminen Klaus=20 [mailto:Klaus.Nieminen@ficora.fi]
Sent: 28 mai 2006=20 16:30
To: speermint@ietf.org
Subject: VS: = [Speermint]=20 Updated Draft: SPEERMINT Peering Architecture

Hi = folks,
 
Richard is right. From the=20 charter:
 
> Issues that are out of scope for SPEERMINT include: =
>
> Routing of sessions which are not signaled using = SIP.=20 In
> particular, SPEERMINT is constrained to consider only = those
>=20 scenarios in which call routing is signaled using the SIP
> = protocol and=20 addressed by SIP or SIPS URIs. E.164 numbers and
> other national = or=20 private formats may only be used as defined
> within the SIP = protocols,=20 and
So SPEERMINT is using = only SIP/SIPS=20 URIs, not E.164 numbers, so there is = no number=20 portability issue for SPEERMINT.
 
However, I understand that = you need a=20 mechanism to do cope with NP also in the SIP interconnection = case and=20 that can be done using infrastructure ENUM (in fact we are now = discussing=20 implementing one in Finland). The right place to=20 discuss infrastructure ENUM is the ENUM WG.
 
I do not know if this is also = out of our=20 current scope, but I would like = to discuss=20 transferring charging/tariff information between providers in realtime.=20 I want to raise this question, = because at=20 least in Finland we have been used to transferring charging information = (pulse=20 charging) in PSTN interconnection interface. This is for example used = also in=20 value added services that are billed by the caller's=20 operator.
And I believe that we = are not only=20 ones that see this capability benefical. In fact it is required, if we = want to=20 enable SIP-based interconnection also for premium rate numbers and I = consider it=20 quite essential.
 
Therefore, I want to = ask that do you=20 see that we need a mechanism to transfer charging data in SIP = interconnection=20 interface and do we have anything ready for that?
 
regards,
 
- Klaus -

L=E4hett=E4j=E4: Stastny Richard=20 [mailto:Richard.Stastny@oefeg.at]
L=E4hetetty: su 28.5.2006=20 11:07
Vastaanottaja: Khan, Sohel Q [CTO]
Kopio:=20 speermint@ietf.org
Aihe: Re: [Speermint] Updated Draft: = SPEERMINT=20 Peering Architecture

I do not know how often I stated here that numbering=20 issues
(and therefore also NUMBER Portability issues) are = out-of-scope
in=20 SPEERMINT

So NUMBER Portablility cannot ne addressed in SPEERMINT = LF

Or we change the SPEERMINT=20 charter

Richard

________________________________

Von= : Khan,=20 Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com]
Gesendet:=20 So 28.05.2006 06:48
An: Stastny Richard; Reinaldo Penno
Cc:=20 speermint@ietf.org
Betreff: RE: [Speermint] Updated Draft: SPEERMINT = Peering=20 Architecture



I think issues of mobility and number = portability=20 need to be addressed together in SPEERMINT LF.

Sohel Khan,=20 Ph.D.
Sprint-Nextel

------=_NextPart_000_0065_01C68304.ADF091D0-- --===============0688167661== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0688167661==-- From speermint-bounces@ietf.org Mon May 29 10:31:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkimC-0001iS-St; Mon, 29 May 2006 10:31:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkimB-0001iN-QA for speermint@ietf.org; Mon, 29 May 2006 10:31:23 -0400 Received: from outbound-red.frontbridge.com ([216.148.222.49] helo=outbound1-red-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkimA-0003HM-Uy for speermint@ietf.org; Mon, 29 May 2006 10:31:23 -0400 Received: from outbound1-red.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-red-R.bigfish.com (Postfix) with ESMTP id 7AE54A131AF; Mon, 29 May 2006 14:31:22 +0000 (UTC) Received: from mail95-red-R.bigfish.com (unknown [172.18.12.1]) by outbound1-red.bigfish.com (Postfix) with ESMTP id 6FFB3A131A6; Mon, 29 May 2006 14:31:22 +0000 (UTC) Received: from mail95-red.bigfish.com (localhost.localdomain [127.0.0.1]) by mail95-red-R.bigfish.com (Postfix) with ESMTP id 620744F9375; Mon, 29 May 2006 14:31:22 +0000 (UTC) X-BigFish: V Received: by mail95-red (MessageSwitch) id 1148913082315994_4381; Mon, 29 May 2006 14:31:22 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail95-red.bigfish.com (Postfix) with ESMTP id 271264F9426; Mon, 29 May 2006 14:31:22 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k4TEV9Ag018345; Mon, 29 May 2006 09:31:13 -0500 (CDT) Received: from plswg01a.ad.sprint.com (PLSWG01A.corp.sprint.com [10.214.11.47]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k4TEUsI11070; Mon, 29 May 2006 09:31:09 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by plswg01a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 09:30:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Mon, 29 May 2006 09:30:06 -0500 Message-ID: <978886E57CC1D64EAFAC157B98E36F9E09159924@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIAEEYoMAAEs7nCAACcsIAAAF4UfQAOV3R4AAcK35gAP5z0YA== From: "Khan, Sohel Q [CTO]" To: "Stastny Richard" X-OriginalArrivalTime: 29 May 2006 14:30:10.0519 (UTC) FILETIME=[63F13670:01C6832C] X-Spam-Score: 0.1 (/) X-Scan-Signature: 958aa603499a3de6b2b87d68741ed60e Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Richard, Would you please describe what LF should perform (in your opinion)? Thanks, Sohel=20 -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Sunday, May 28, 2006 3:07 AM To: Khan, Sohel Q [CTO] Cc: speermint@ietf.org Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture I do not know how often I stated here that numbering issues (and therefore also NUMBER Portability issues) are out-of-scope in SPEERMINT =20 So NUMBER Portablility cannot ne addressed in SPEERMINT LF =20 Or we change the SPEERMINT charter =20 Richard ________________________________ Von: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] Gesendet: So 28.05.2006 06:48 An: Stastny Richard; Reinaldo Penno Cc: speermint@ietf.org Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture I think issues of mobility and number portability need to be addressed together in SPEERMINT LF. Sohel Khan, Ph.D. Sprint-Nextel -----Original Message----- From: "Stastny Richard" To: "Reinaldo Penno" Cc: "speermint@ietf.org" Sent: 5/27/06 4:52 PM Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture What question? Richard ________________________________ Von: Reinaldo Penno [mailto:rpenno@juniper.net] Gesendet: Sa 27.05.2006 23:46 An: Stastny Richard Cc: speermint@ietf.org Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Apart form your outside-of-the-us rhetoric the questions remains. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Saturday, May 27, 2006 2:38 PM > To: Reinaldo Penno > Cc: speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > ENUM issues should not be discussed in SPEERMINT, just some questions > > >Enum? When I dial (650) 453 2312, what is there to resolve _inside_ the > >wireless network that owns this number apart from the location of the > >user? > > and _outside_? > ENUM is about numbers like +16504532312 > > hello, we are talking E.164 numbers in ENUM, which is international=20 > numbers > > >Now, in the scenario where an external call (for example, a cingular=20 > >customer calling a Verizon customer (which owns an original t-mobile=20 > >number). How that works today? If you say ENUM I would stand corrected > >(and surprised), since LNP has been fully deployed since 2003. > > Cingular?Verizon? ... > > we are talking about a global solution here You are a bit US centric=20 > here, there is also some 200 other nations ozt there. > > I have no access to the US LNP database from e.g. Austria > > So you want to consider US national databases only in speermint? > > Richard > > > > ________________________________ > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Sa 27.05.2006 21:30 > An: Stastny Richard; Otmar Lendl > Cc: speermint@ietf.org > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > Enum? When I dial (650) 453 2312, what is there to resolve _inside_ the > wireless network that owns this number apart from the location of the=20 > user? > > > Now, in the scenario where an external call (for example, a cingular=20 > customer calling a Verizon customer (which owns an original t-mobile=20 > number). How that works today? If you say ENUM I would stand corrected > (and surprised), since LNP has been fully deployed since 2003. > > When a user takes its number with them, I assumed this punches a whole > in the telephone prefix hierarchy and a specific entry somewhere is=20 > needed. > > Regards, > > Reinaldo > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Saturday, May 27, 2006 4:26 AM > > To: Reinaldo Penno; Otmar Lendl > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > >I wonder how > > >LNP is solved within wireless...A specific entry for each phone? That > > >would be crazy. > > > > Ahem, ENUM? > > > > I thought that is all what ENUM is about? > > > > Richard > > > > > > ________________________________ > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > Gesendet: Sa 27.05.2006 11:04 > > An: Otmar Lendl; Patrick Melampy > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > > > > > Hello, > > > > I believe the crux of the problem was missed. > > > > The issue is not really the number of domains. We have today some=20 > > 400.000.000 million hosts on the Internet. BGP peers to do not > exchange > > 400.000.000 million routes, they exchange in the low hundreds of=20 > > thousands. > > > > And why is that? (I guess you know where I'm getting at). That's > because > > IP addresses lend themselves very well to hierarchical deployment,=20 > > compression through prefix/CIDR usage and the like. DNS names are=20 > > strings and hence difficult to come up with a similar scheme. > > > > > > I believe that if domains need to be exchanged between peers: > > > > 1 - Just a limited set would be exchanged and a "default layer 5 > route" > > (equivalent to a traditional default route) would be used. > > > > 2 - Compression schemes like *.company.com, regular expressions or the > > like would need to be used. Having specific routes to AORs would be=20 > > hairy (maybe for the eventual roaming or visiting user). I wonder how > > LNP is solved within wireless...A specific entry for each phone? That > > would be crazy. > > > > 3 - Some new scheme that will make somebody rich....until then.. > > > > I believe subscriptions would be used to exchange mostly "cost" and=20 > > policy information and some domains. I use cost here in the layer 3=20 > > sense (number of calls, jitter, whatever). Cost would be an abstract > > value or a more specific one (up to the administrator). > > > > Regards, > > > > Reinaldo > > > > > -----Original Message----- > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > Sent: Saturday, May 27, 2006 1:29 AM > > > To: Patrick Melampy > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > > > > > > On 2006/05/26 18:05, Patrick Melampy > wrote: > > > > I suppose like in any distributed routing protocol, there are some > > > chicken > > > > an egg issues. But consider the following. > > > > > > > > PREREQUISITES: > > > > 1.) You know the destination DOMAIN from either ENUM or other > means. > > > > > > [...] > > > > > > > > This technique is very similar to TRIP, only its for DOMAINS and > not > > > partial > > > > E.164 numbers. > > > > > > [...] > > > > > > > Obviously, the data set could get large, as the list of domains > can > > be > > > > really big. There are some possibilities here... > > > > > > Let's do a quick estimate on the number of domains involved: > > > > > > Right now, operators usually give customers URIs of the form=20 > > > @. As long as this is the state of affairs, > > > we're fine as the number of providers is quite finite (a few=20 > > > thousands, perhaps). > > > > > > This is like the state of affairs with respect to email, anno 1990. > > > Back then customers started to notice that if they use their own > > domain > > > for email, then they can switch providers without having to change > > > their email address. Thus a *lot* of people opted to use their own > > > domain for email. > > > > > > My guess is that the same will happen to SIP. Once customers print > > > their SIP uris on business cards, they will want to use their own=20 > > > domains. If providers won't support that feature then I suspect that > > > the regulators will step in and mandate an URI portability solution > > > just as they did in the PSTN with respect to numbers from number > > blocks. > > > (This could get really nasty protocol-wise, so I guess using > customer- > > > owned domains is the far better and likelier solution to the porting > > > question.) > > > > > > So: Anything we come up with here in SPEERMINT needs to cope with a > > > scenario where the use of customer domains in SIP URIs is just as=20 > > > widespread as it is for email. > > > > > > How many domains are used for email? That's hard to say. There are > > > about 60 million gTLD domains and probably more than 20 ccTLD ones. > > > Assuming that only a tenth of that is used for email we're at > > > 8 million domains. Given the exponential growth any system which=20 > > > doesn't scale to at least 10 million domains will be obsolete before > > > the ink is dry on the RFC. > > > > > > So what happens if we do some sort of BGP or TRIP with domains? > > > > > > Let's say we need at least 100 bytes of state information per > domain. > > > That makes a full routing table 1 GB worth of data. That also means > > > that a new border element needs to exchange that amount of data=20 > > > with its peers before it has learned the current state of the=20 > > > routing table. > > > > > > That is some serious amount of data. > > > > > > > 1.) Have notification point to a published document, and the > > document > > > lists > > > > all of the relevant reachability in real time. Thus any change to > > the > > > > document would generate a NOTIFICATION. > > > > > > + a download of up to 1 GB per peer. > > > > > > > 2.) User partial domains, broken up by the "dots". This may allow > > some > > > > wildcarding to reduce the number of domains. For instance, a > carrier > > > like > > > > Verizon may have many 100's of domains attached to it, and version > > is > > > > willing to route and manage SIP traffic to any of them. The NOTIFY > > could > > > > contain something like: Verizon.com or *.verizon.com to indicate > > that > > > any > > > > domain in Verizon is reachable. > > > > > > That's helpful if a provider uses subdomains for internal purposes, > > > but that won't help you with customer owned domains. > > > > > > > This technique may work -- and fit nicely into an existing > protocol. > > All > > > we > > > > would need to do is define the data models (XML?) and or documents > > for > > > > exchanging. > > > > > > I think this technique can work -- if you add an aggregation step=20 > > > before the routing scheme. > > > > > > Take another look at BGP: there you have the concept of an=20 > > > Autonomous System and not only that of prefixes. Maybe you need=20 > > > something similar. > > > > > > One approach to cope with hosted SIP domains could be to use the=20 > > > hostnames as found in SRV records. E.g. for settings like > > > > > > _sip._tcp.customer.domain IN SRV 10 10 5060 sip.provider.com > > > > > > run the routing algorithm on "sip.provider.com" instead of=20 > > > "customer.domain". > > > > > > Another option is to store some AS-equivalent in the customer domain > > > and have the routing algorithm operate on that. In my domain-policy > > > framework this could be expressed e.g. like > > > > > > customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > stating that this domain can be reached using the Speermint routing > > > logic by using the learned route to RoutingID 1042. > > > > > > Or, even better, use non-terminals, and thus refer to the ingress=20 > > > policy stored in the provider's domain: > > > > > > customers.domain IN NAPTR "" 10 10 "D2P+SIP" "" provider.com > > > > > > provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > (+ whatever other facts provider.com wants to announce about his > > > reachability.) > > > > > > This combination of our ideas can indeed work and scale to an=20 > > > unlimited number of customer-owned domains. > > > > > > /ol > > > -- > > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon May 29 11:13:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkjQi-00083t-Cl; Mon, 29 May 2006 11:13:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkjQh-00083n-QO for speermint@ietf.org; Mon, 29 May 2006 11:13:15 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkjQh-0005iC-NV for speermint@ietf.org; Mon, 29 May 2006 11:13:15 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FkjFT-000620-0V for speermint@ietf.org; Mon, 29 May 2006 11:01:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Mon, 29 May 2006 17:05:36 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4FEB@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIAEEYoMAAEs7nCAACcsIAAAF4UfQAOV3R4AAcK35gAP5z0YAAA2P8g From: "Stastny Richard" To: "Khan, Sohel Q [CTO]" X-Spam-Score: -2.5 (--) X-Scan-Signature: c40ff0c70161549dbde2f89c7946385a Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Sohel, I posted this already on Friday, but I think everybody (including me) lost track already;-) So here once again: "May I try my summary: the Location function is a process containing eventually more then one step: "If you start with the CRD (e.g a SIP AoR entered by the User=20 or derived from ENUM)" Remark: Whith this I ment that the E.164 to SIP URI mapping is already done, because this is out-of-scope of SPEERMINT. In addition, SPEERMINT MUST be able to work in the same way if the user has entered a SIP URI direct. This is why I prefer that the result of an ENUM query is an AoR and not directly the ingress element to the destination network. "1. The AoR gives you the destination network=20 2. You need to locate the peering club (=3D federation) for=20 exchanging SIP messages (L5 )with the destination network 3. so you need to locate the policy you want to use and=20 make a decision on the federation (note: a destination network may belong to more then one federations)" (Remark: both origination network and destination network may be members of more then one federation. They may need to locate a common one. If more then one federation is in common, it is the choice of the origination network to select one - So the Policy Function is embedded in the LF) 4. "having chosen a federation, you need to locate the ingress=20 proxy(ies) the destination network is using within this federation. 5. If you are using a separate peering for exchanging media, you now may locate these" Additional remark: In step 4. and 5. some geographic location magic could come into play as requested by some on this list. Regards Richard > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: Monday, May 29, 2006 4:30 PM > To: Stastny Richard > Cc: speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > Richard, >=20 > Would you please describe what LF should perform (in your opinion)? >=20 >=20 > Thanks, >=20 > Sohel >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Sunday, May 28, 2006 3:07 AM > To: Khan, Sohel Q [CTO] > Cc: speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > I do not know how often I stated here that numbering issues (and > therefore also NUMBER Portability issues) are out-of-scope in SPEERMINT >=20 > So NUMBER Portablility cannot ne addressed in SPEERMINT LF >=20 > Or we change the SPEERMINT charter >=20 > Richard >=20 > ________________________________ >=20 > Von: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Gesendet: So 28.05.2006 06:48 > An: Stastny Richard; Reinaldo Penno > Cc: speermint@ietf.org > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 >=20 >=20 > I think issues of mobility and number portability need to be addressed > together in SPEERMINT LF. >=20 > Sohel Khan, Ph.D. > Sprint-Nextel >=20 > -----Original Message----- > From: "Stastny Richard" > To: "Reinaldo Penno" > Cc: "speermint@ietf.org" > Sent: 5/27/06 4:52 PM > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > What question? > Richard >=20 > ________________________________ >=20 > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Sa 27.05.2006 23:46 > An: Stastny Richard > Cc: speermint@ietf.org > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 >=20 >=20 > Apart form your outside-of-the-us rhetoric the questions remains. >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Saturday, May 27, 2006 2:38 PM > > To: Reinaldo Penno > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > ENUM issues should not be discussed in SPEERMINT, just some questions > > > > >Enum? When I dial (650) 453 2312, what is there to resolve _inside_ > the > > >wireless network that owns this number apart from the location of the >=20 > > >user? > > > > and _outside_? > > ENUM is about numbers like +16504532312 > > > > hello, we are talking E.164 numbers in ENUM, which is international > > numbers > > > > >Now, in the scenario where an external call (for example, a cingular > > >customer calling a Verizon customer (which owns an original t-mobile > > >number). How that works today? If you say ENUM I would stand > corrected > > >(and surprised), since LNP has been fully deployed since 2003. > > > > Cingular?Verizon? ... > > > > we are talking about a global solution here You are a bit US centric > > here, there is also some 200 other nations ozt there. > > > > I have no access to the US LNP database from e.g. Austria > > > > So you want to consider US national databases only in speermint? > > > > Richard > > > > > > > > ________________________________ > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > Gesendet: Sa 27.05.2006 21:30 > > An: Stastny Richard; Otmar Lendl > > Cc: speermint@ietf.org > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > > > > > Enum? When I dial (650) 453 2312, what is there to resolve _inside_ > the > > wireless network that owns this number apart from the location of the > > user? > > > > > > Now, in the scenario where an external call (for example, a cingular > > customer calling a Verizon customer (which owns an original t-mobile > > number). How that works today? If you say ENUM I would stand corrected >=20 > > (and surprised), since LNP has been fully deployed since 2003. > > > > When a user takes its number with them, I assumed this punches a whole >=20 > > in the telephone prefix hierarchy and a specific entry somewhere is > > needed. > > > > Regards, > > > > Reinaldo > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Saturday, May 27, 2006 4:26 AM > > > To: Reinaldo Penno; Otmar Lendl > > > Cc: speermint@ietf.org > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > > > > > > >I wonder how > > > >LNP is solved within wireless...A specific entry for each phone? > That > > > >would be crazy. > > > > > > Ahem, ENUM? > > > > > > I thought that is all what ENUM is about? > > > > > > Richard > > > > > > > > > ________________________________ > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Gesendet: Sa 27.05.2006 11:04 > > > An: Otmar Lendl; Patrick Melampy > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org > > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > > > > > > > > > > > > Hello, > > > > > > I believe the crux of the problem was missed. > > > > > > The issue is not really the number of domains. We have today some > > > 400.000.000 million hosts on the Internet. BGP peers to do not > > exchange > > > 400.000.000 million routes, they exchange in the low hundreds of > > > thousands. > > > > > > And why is that? (I guess you know where I'm getting at). That's > > because > > > IP addresses lend themselves very well to hierarchical deployment, > > > compression through prefix/CIDR usage and the like. DNS names are > > > strings and hence difficult to come up with a similar scheme. > > > > > > > > > I believe that if domains need to be exchanged between peers: > > > > > > 1 - Just a limited set would be exchanged and a "default layer 5 > > route" > > > (equivalent to a traditional default route) would be used. > > > > > > 2 - Compression schemes like *.company.com, regular expressions or > the > > > like would need to be used. Having specific routes to AORs would be > > > hairy (maybe for the eventual roaming or visiting user). I wonder > how > > > LNP is solved within wireless...A specific entry for each phone? > That > > > would be crazy. > > > > > > 3 - Some new scheme that will make somebody rich....until then.. > > > > > > I believe subscriptions would be used to exchange mostly "cost" and > > > policy information and some domains. I use cost here in the layer 3 > > > sense (number of calls, jitter, whatever). Cost would be an abstract >=20 > > > value or a more specific one (up to the administrator). > > > > > > Regards, > > > > > > Reinaldo > > > > > > > -----Original Message----- > > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > > Sent: Saturday, May 27, 2006 1:29 AM > > > > To: Patrick Melampy > > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > > Architecture > > > > > > > > On 2006/05/26 18:05, Patrick Melampy > > wrote: > > > > > I suppose like in any distributed routing protocol, there are > some > > > > chicken > > > > > an egg issues. But consider the following. > > > > > > > > > > PREREQUISITES: > > > > > 1.) You know the destination DOMAIN from either ENUM or other > > means. > > > > > > > > [...] > > > > > > > > > > This technique is very similar to TRIP, only its for DOMAINS and > > not > > > > partial > > > > > E.164 numbers. > > > > > > > > [...] > > > > > > > > > Obviously, the data set could get large, as the list of domains > > can > > > be > > > > > really big. There are some possibilities here... > > > > > > > > Let's do a quick estimate on the number of domains involved: > > > > > > > > Right now, operators usually give customers URIs of the form > > > > @. As long as this is the state of > affairs, > > > > we're fine as the number of providers is quite finite (a few > > > > thousands, perhaps). > > > > > > > > This is like the state of affairs with respect to email, anno > 1990. > > > > Back then customers started to notice that if they use their own > > > domain > > > > for email, then they can switch providers without having to change >=20 > > > > their email address. Thus a *lot* of people opted to use their own >=20 > > > > domain for email. > > > > > > > > My guess is that the same will happen to SIP. Once customers print >=20 > > > > their SIP uris on business cards, they will want to use their own > > > > domains. If providers won't support that feature then I suspect > that > > > > the regulators will step in and mandate an URI portability > solution > > > > just as they did in the PSTN with respect to numbers from number > > > blocks. > > > > (This could get really nasty protocol-wise, so I guess using > > customer- > > > > owned domains is the far better and likelier solution to the > porting > > > > question.) > > > > > > > > So: Anything we come up with here in SPEERMINT needs to cope with > a > > > > scenario where the use of customer domains in SIP URIs is just as > > > > widespread as it is for email. > > > > > > > > How many domains are used for email? That's hard to say. There are >=20 > > > > about 60 million gTLD domains and probably more than 20 ccTLD > ones. > > > > Assuming that only a tenth of that is used for email we're at > > > > 8 million domains. Given the exponential growth any system which > > > > doesn't scale to at least 10 million domains will be obsolete > before > > > > the ink is dry on the RFC. > > > > > > > > So what happens if we do some sort of BGP or TRIP with domains? > > > > > > > > Let's say we need at least 100 bytes of state information per > > domain. > > > > That makes a full routing table 1 GB worth of data. That also > means > > > > that a new border element needs to exchange that amount of data > > > > with its peers before it has learned the current state of the > > > > routing table. > > > > > > > > That is some serious amount of data. > > > > > > > > > 1.) Have notification point to a published document, and the > > > document > > > > lists > > > > > all of the relevant reachability in real time. Thus any change > to > > > the > > > > > document would generate a NOTIFICATION. > > > > > > > > + a download of up to 1 GB per peer. > > > > > > > > > 2.) User partial domains, broken up by the "dots". This may > allow > > > some > > > > > wildcarding to reduce the number of domains. For instance, a > > carrier > > > > like > > > > > Verizon may have many 100's of domains attached to it, and > version > > > is > > > > > willing to route and manage SIP traffic to any of them. The > NOTIFY > > > could > > > > > contain something like: Verizon.com or *.verizon.com to indicate > > > that > > > > any > > > > > domain in Verizon is reachable. > > > > > > > > That's helpful if a provider uses subdomains for internal > purposes, > > > > but that won't help you with customer owned domains. > > > > > > > > > This technique may work -- and fit nicely into an existing > > protocol. > > > All > > > > we > > > > > would need to do is define the data models (XML?) and or > documents > > > for > > > > > exchanging. > > > > > > > > I think this technique can work -- if you add an aggregation step > > > > before the routing scheme. > > > > > > > > Take another look at BGP: there you have the concept of an > > > > Autonomous System and not only that of prefixes. Maybe you need > > > > something similar. > > > > > > > > One approach to cope with hosted SIP domains could be to use the > > > > hostnames as found in SRV records. E.g. for settings like > > > > > > > > _sip._tcp.customer.domain IN SRV 10 10 5060 sip.provider.com > > > > > > > > run the routing algorithm on "sip.provider.com" instead of > > > > "customer.domain". > > > > > > > > Another option is to store some AS-equivalent in the customer > domain > > > > and have the routing algorithm operate on that. In my > domain-policy > > > > framework this could be expressed e.g. like > > > > > > > > customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > > > stating that this domain can be reached using the Speermint > routing > > > > logic by using the learned route to RoutingID 1042. > > > > > > > > Or, even better, use non-terminals, and thus refer to the ingress > > > > policy stored in the provider's domain: > > > > > > > > customers.domain IN NAPTR "" 10 10 "D2P+SIP" "" provider.com > > > > > > > > provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > > > (+ whatever other facts provider.com wants to announce about his > > > > reachability.) > > > > > > > > This combination of our ideas can indeed work and scale to an > > > > unlimited number of customer-owned domains. > > > > > > > > /ol > > > > -- > > > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 >=20 >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon May 29 15:13:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FknAr-0000wS-FB; Mon, 29 May 2006 15:13:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FknAq-0000wG-AA for speermint@ietf.org; Mon, 29 May 2006 15:13:08 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FknAq-000745-7J for speermint@ietf.org; Mon, 29 May 2006 15:13:08 -0400 Received: from outbound-cpk.frontbridge.com ([207.46.163.16] helo=outbound1-cpk-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FkmvM-0001mW-Cv for speermint@ietf.org; Mon, 29 May 2006 14:57:11 -0400 Received: from outbound1-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-cpk-R.bigfish.com (Postfix) with ESMTP id 94550ABCC05; Mon, 29 May 2006 18:57:07 +0000 (UTC) Received: from mail75-cpk-R.bigfish.com (unknown [192.168.21.3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by outbound1-cpk.bigfish.com (Postfix) with ESMTP id 8B506ABCC03; Mon, 29 May 2006 18:57:07 +0000 (UTC) Received: from mail75-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by mail75-cpk-R.bigfish.com (Postfix) with ESMTP id 3AF57406F72; Mon, 29 May 2006 18:57:07 +0000 (UTC) X-BigFish: V Received: by mail75-cpk (MessageSwitch) id 1148929027148080_23336; Mon, 29 May 2006 18:57:07 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail75-cpk.bigfish.com (Postfix) with ESMTP id E7CD8406CFC; Mon, 29 May 2006 18:57:06 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id k4TIuMDt003252; Mon, 29 May 2006 13:56:37 -0500 (CDT) Received: from pdawg06a.ad.sprint.com (PDAWG06A.corp.sprint.com [10.122.2.33]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k4TIuLI28076; Mon, 29 May 2006 13:56:22 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by pdawg06a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 13:55:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 May 2006 13:55:36 -0500 Message-ID: <978886E57CC1D64EAFAC157B98E36F9E091599CE@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Defining Location Function (RE: Updated Draft: SPEERMINT Peering Architecture) Thread-Index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIAEEYoMAAEs7nCAACcsIAAAF4UfQAOV3R4AAcK35gAP5z0YAAA2P8gAAgEsSA= From: "Khan, Sohel Q [CTO]" To: "Stastny Richard" X-OriginalArrivalTime: 29 May 2006 18:55:37.0807 (UTC) FILETIME=[79587DF0:01C68351] X-Spam-Score: -2.6 (--) X-Scan-Signature: a2c4a3535d1556ada67f8703d3d31591 Cc: speermint@ietf.org Subject: [Speermint] Defining Location Function (RE: Updated Draft: SPEERMINT Peering Architecture) X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org =20 Is it possible to take lessons from hierarchical eBGP routing? We can consider each provider as the Autonomous System (say Level 0), a federation is a hierarchical Autonomous system (say Level 1) that contains a group of Autonomous-system (level 0). Hierarchical Autonomous system's (Level 1) SIP route-database (as opposed to the BGP routing table) is the Location Function (LF). SIP call routing feature will be destination-based, path-vector based, and policy based similar to BGP features. I am trying to initiate a discussion in a different angle. Thanks, Sohel Khan, Ph.D. Technology Strategist Sprint-Nextel 913-794-1470 (office) 913-486-3145 (cell) -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Monday, May 29, 2006 10:06 AM To: Khan, Sohel Q [CTO] Cc: speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Sohel, I posted this already on Friday, but I think everybody (including me) lost track already;-) So here once again: "May I try my summary: the Location function is a process containing eventually more then one step: "If you start with the CRD (e.g a SIP AoR entered by the User or derived from ENUM)" Remark: Whith this I ment that the E.164 to SIP URI mapping is already done, because this is out-of-scope of SPEERMINT. In addition, SPEERMINT MUST be able to work in the same way if the user has entered a SIP URI direct. This is why I prefer that the result of an ENUM query is an AoR and not directly the ingress element to the destination network. "1. The AoR gives you the destination network=20 2. You need to locate the peering club (=3D federation) for exchanging = SIP messages (L5 )with the destination network 3. so you need to locate the policy you want to use and make a decision on the federation (note: a destination network may belong to more then one federations)" (Remark: both origination network and destination network may be members of more then one federation. They may need to locate a common one. If more then one federation is in common, it is the choice of the origination network to select one - So the Policy Function is embedded in the LF) 4. "having chosen a federation, you need to locate the ingress proxy(ies) the destination network is using within this federation. 5. If you are using a separate peering for exchanging media, you now may locate these" Additional remark: In step 4. and 5. some geographic location magic could come into play as requested by some on this list. Regards Richard > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: Monday, May 29, 2006 4:30 PM > To: Stastny Richard > Cc: speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > Richard, >=20 > Would you please describe what LF should perform (in your opinion)? >=20 >=20 > Thanks, >=20 > Sohel >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Sunday, May 28, 2006 3:07 AM > To: Khan, Sohel Q [CTO] > Cc: speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > I do not know how often I stated here that numbering issues (and=20 > therefore also NUMBER Portability issues) are out-of-scope in SPEERMINT >=20 > So NUMBER Portablility cannot ne addressed in SPEERMINT LF >=20 > Or we change the SPEERMINT charter >=20 > Richard >=20 > ________________________________ >=20 > Von: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Gesendet: So 28.05.2006 06:48 > An: Stastny Richard; Reinaldo Penno > Cc: speermint@ietf.org > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 >=20 >=20 > I think issues of mobility and number portability need to be addressed > together in SPEERMINT LF. >=20 > Sohel Khan, Ph.D. > Sprint-Nextel >=20 > -----Original Message----- > From: "Stastny Richard" > To: "Reinaldo Penno" > Cc: "speermint@ietf.org" > Sent: 5/27/06 4:52 PM > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > What question? > Richard >=20 > ________________________________ >=20 > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Sa 27.05.2006 23:46 > An: Stastny Richard > Cc: speermint@ietf.org > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 >=20 >=20 > Apart form your outside-of-the-us rhetoric the questions remains. >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Saturday, May 27, 2006 2:38 PM > > To: Reinaldo Penno > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > ENUM issues should not be discussed in SPEERMINT, just some questions > > > > >Enum? When I dial (650) 453 2312, what is there to resolve _inside_ > the > > >wireless network that owns this number apart from the location of the >=20 > > >user? > > > > and _outside_? > > ENUM is about numbers like +16504532312 > > > > hello, we are talking E.164 numbers in ENUM, which is international=20 > > numbers > > > > >Now, in the scenario where an external call (for example, a cingular > > >customer calling a Verizon customer (which owns an original t-mobile > > >number). How that works today? If you say ENUM I would stand > corrected > > >(and surprised), since LNP has been fully deployed since 2003. > > > > Cingular?Verizon? ... > > > > we are talking about a global solution here You are a bit US centric > > here, there is also some 200 other nations ozt there. > > > > I have no access to the US LNP database from e.g. Austria > > > > So you want to consider US national databases only in speermint? > > > > Richard > > > > > > > > ________________________________ > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > Gesendet: Sa 27.05.2006 21:30 > > An: Stastny Richard; Otmar Lendl > > Cc: speermint@ietf.org > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > > > > > Enum? When I dial (650) 453 2312, what is there to resolve _inside_ > the > > wireless network that owns this number apart from the location of the > > user? > > > > > > Now, in the scenario where an external call (for example, a cingular > > customer calling a Verizon customer (which owns an original t-mobile > > number). How that works today? If you say ENUM I would stand corrected >=20 > > (and surprised), since LNP has been fully deployed since 2003. > > > > When a user takes its number with them, I assumed this punches a whole >=20 > > in the telephone prefix hierarchy and a specific entry somewhere is=20 > > needed. > > > > Regards, > > > > Reinaldo > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Saturday, May 27, 2006 4:26 AM > > > To: Reinaldo Penno; Otmar Lendl > > > Cc: speermint@ietf.org > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > > > > > > >I wonder how > > > >LNP is solved within wireless...A specific entry for each phone? > That > > > >would be crazy. > > > > > > Ahem, ENUM? > > > > > > I thought that is all what ENUM is about? > > > > > > Richard > > > > > > > > > ________________________________ > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Gesendet: Sa 27.05.2006 11:04 > > > An: Otmar Lendl; Patrick Melampy > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org > > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > > > > > > > > > > > > Hello, > > > > > > I believe the crux of the problem was missed. > > > > > > The issue is not really the number of domains. We have today some=20 > > > 400.000.000 million hosts on the Internet. BGP peers to do not > > exchange > > > 400.000.000 million routes, they exchange in the low hundreds of=20 > > > thousands. > > > > > > And why is that? (I guess you know where I'm getting at). That's > > because > > > IP addresses lend themselves very well to hierarchical deployment, > > > compression through prefix/CIDR usage and the like. DNS names are=20 > > > strings and hence difficult to come up with a similar scheme. > > > > > > > > > I believe that if domains need to be exchanged between peers: > > > > > > 1 - Just a limited set would be exchanged and a "default layer 5 > > route" > > > (equivalent to a traditional default route) would be used. > > > > > > 2 - Compression schemes like *.company.com, regular expressions or > the > > > like would need to be used. Having specific routes to AORs would be > > > hairy (maybe for the eventual roaming or visiting user). I wonder > how > > > LNP is solved within wireless...A specific entry for each phone? > That > > > would be crazy. > > > > > > 3 - Some new scheme that will make somebody rich....until then.. > > > > > > I believe subscriptions would be used to exchange mostly "cost" and > > > policy information and some domains. I use cost here in the layer 3 > > > sense (number of calls, jitter, whatever). Cost would be an abstract >=20 > > > value or a more specific one (up to the administrator). > > > > > > Regards, > > > > > > Reinaldo > > > > > > > -----Original Message----- > > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > > Sent: Saturday, May 27, 2006 1:29 AM > > > > To: Patrick Melampy > > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > > Architecture > > > > > > > > On 2006/05/26 18:05, Patrick Melampy > > wrote: > > > > > I suppose like in any distributed routing protocol, there are > some > > > > chicken > > > > > an egg issues. But consider the following. > > > > > > > > > > PREREQUISITES: > > > > > 1.) You know the destination DOMAIN from either ENUM or other > > means. > > > > > > > > [...] > > > > > > > > > > This technique is very similar to TRIP, only its for DOMAINS and > > not > > > > partial > > > > > E.164 numbers. > > > > > > > > [...] > > > > > > > > > Obviously, the data set could get large, as the list of domains > > can > > > be > > > > > really big. There are some possibilities here... > > > > > > > > Let's do a quick estimate on the number of domains involved: > > > > > > > > Right now, operators usually give customers URIs of the form=20 > > > > @. As long as this is the state of > affairs, > > > > we're fine as the number of providers is quite finite (a few=20 > > > > thousands, perhaps). > > > > > > > > This is like the state of affairs with respect to email, anno > 1990. > > > > Back then customers started to notice that if they use their own > > > domain > > > > for email, then they can switch providers without having to change >=20 > > > > their email address. Thus a *lot* of people opted to use their own >=20 > > > > domain for email. > > > > > > > > My guess is that the same will happen to SIP. Once customers print >=20 > > > > their SIP uris on business cards, they will want to use their own > > > > domains. If providers won't support that feature then I suspect > that > > > > the regulators will step in and mandate an URI portability > solution > > > > just as they did in the PSTN with respect to numbers from number > > > blocks. > > > > (This could get really nasty protocol-wise, so I guess using > > customer- > > > > owned domains is the far better and likelier solution to the > porting > > > > question.) > > > > > > > > So: Anything we come up with here in SPEERMINT needs to cope with > a > > > > scenario where the use of customer domains in SIP URIs is just as > > > > widespread as it is for email. > > > > > > > > How many domains are used for email? That's hard to say. There are >=20 > > > > about 60 million gTLD domains and probably more than 20 ccTLD > ones. > > > > Assuming that only a tenth of that is used for email we're at > > > > 8 million domains. Given the exponential growth any system which > > > > doesn't scale to at least 10 million domains will be obsolete > before > > > > the ink is dry on the RFC. > > > > > > > > So what happens if we do some sort of BGP or TRIP with domains? > > > > > > > > Let's say we need at least 100 bytes of state information per > > domain. > > > > That makes a full routing table 1 GB worth of data. That also > means > > > > that a new border element needs to exchange that amount of data=20 > > > > with its peers before it has learned the current state of the=20 > > > > routing table. > > > > > > > > That is some serious amount of data. > > > > > > > > > 1.) Have notification point to a published document, and the > > > document > > > > lists > > > > > all of the relevant reachability in real time. Thus any change > to > > > the > > > > > document would generate a NOTIFICATION. > > > > > > > > + a download of up to 1 GB per peer. > > > > > > > > > 2.) User partial domains, broken up by the "dots". This may > allow > > > some > > > > > wildcarding to reduce the number of domains. For instance, a > > carrier > > > > like > > > > > Verizon may have many 100's of domains attached to it, and > version > > > is > > > > > willing to route and manage SIP traffic to any of them. The > NOTIFY > > > could > > > > > contain something like: Verizon.com or *.verizon.com to indicate > > > that > > > > any > > > > > domain in Verizon is reachable. > > > > > > > > That's helpful if a provider uses subdomains for internal > purposes, > > > > but that won't help you with customer owned domains. > > > > > > > > > This technique may work -- and fit nicely into an existing > > protocol. > > > All > > > > we > > > > > would need to do is define the data models (XML?) and or > documents > > > for > > > > > exchanging. > > > > > > > > I think this technique can work -- if you add an aggregation step > > > > before the routing scheme. > > > > > > > > Take another look at BGP: there you have the concept of an=20 > > > > Autonomous System and not only that of prefixes. Maybe you need=20 > > > > something similar. > > > > > > > > One approach to cope with hosted SIP domains could be to use the > > > > hostnames as found in SRV records. E.g. for settings like > > > > > > > > _sip._tcp.customer.domain IN SRV 10 10 5060 sip.provider.com > > > > > > > > run the routing algorithm on "sip.provider.com" instead of=20 > > > > "customer.domain". > > > > > > > > Another option is to store some AS-equivalent in the customer > domain > > > > and have the routing algorithm operate on that. In my > domain-policy > > > > framework this could be expressed e.g. like > > > > > > > > customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > > > stating that this domain can be reached using the Speermint > routing > > > > logic by using the learned route to RoutingID 1042. > > > > > > > > Or, even better, use non-terminals, and thus refer to the ingress > > > > policy stored in the provider's domain: > > > > > > > > customers.domain IN NAPTR "" 10 10 "D2P+SIP" "" provider.com > > > > > > > > provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > > > (+ whatever other facts provider.com wants to announce about his > > > > reachability.) > > > > > > > > This combination of our ideas can indeed work and scale to an=20 > > > > unlimited number of customer-owned domains. > > > > > > > > /ol > > > > -- > > > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 >=20 >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon May 29 17:36:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkpPJ-0000JK-Ip; Mon, 29 May 2006 17:36:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkpPI-0000G0-KF for speermint@ietf.org; Mon, 29 May 2006 17:36:12 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkpPH-0004dA-TS for speermint@ietf.org; Mon, 29 May 2006 17:36:12 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 29 May 2006 14:36:11 -0700 X-IronPort-AV: i="4.05,184,1146466800"; d="scan'208"; a="554538255:sNHT42156656" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] LNP today and routing by domain tomorrow Date: Mon, 29 May 2006 17:36:08 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804652EA3@proton.jnpr.net> In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0CE77E9A@ACCLUST02EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] LNP today and routing by domain tomorrow Thread-Index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIAEEYoMABohKwAAACfAGA= From: "Reinaldo Penno" To: "Pfautz, Penn L, GBLAM" , "Stastny Richard" , "Otmar Lendl" X-Spam-Score: 0.0 (/) X-Scan-Signature: b058151374d77ee76edaac850f7449fb Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > -----Original Message----- > From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] > Sent: Monday, May 29, 2006 2:18 PM > To: Reinaldo Penno; Stastny Richard; Otmar Lendl > Subject: RE: [Speermint] LNP today and routing by domain tomorrow >=20 > A couple of things: >=20 > 1. Re how is LNP implemented today. Yes, in the rational implementation > (i.e., all call query) there is an entry for every ported away number. > You can no longer route on dialed central office code and that is why > ENUM has a Tier 1 at the per-number level. > In terms of mobility, calls go to their home switch first and are then > routed to wherever the subscriber is roaming. [[Reinaldo]]=20 Thanks for he explanation. That was what I was looking for. >=20 > 2. In terms of exchanging domain info. I'm not sure I follow the > scenario. I don't expect so many domains to be relevant if peering is > service provider to service provider. If everybody really doesn't use > E.164 but chooses to reinvent the wheel again by having their own > domain, then we'll need DNS RRs that specify a VoIP service provider > similar to what infrastructure ENUM will do for E.164. > Am I missing something? [[Reinaldo]]=20 Scenario is this: * bob@companyA.com wants to make a VoIP call to alice@companyB.com (E.164 numbers are never used in this case). * A DNS resolution of @companyB.com return bigproviderA.com that provides VoIP service to company A. * Packet goes to some SIP proxy in bigproviderA.com Now some options are presented: bigproviderA.com can make a DNS request and receive a proxy in companyB.com (we are basically done). Another option is that the DNS resolution will return bigproviderB.com (which provides VoIP service to company B). When crossing from providerA to providerB, SIP subscriptions/notifies will allow making a more informed choice on where to cross, specific SIP proxy at a certain location to use, etc, etc.=20 Another option is that some relevant domains could be exchanged in subscription/notify messages, so that instead of making a DNS resolution to find out the proxy in providerB, provider's A proxy will consult its subscription data and find out the "closest proxy", less costly, or whatever. DNS data could be an input to this decision too. This is the 10000 foot view.=20 I'm writing a draft with some other colleagues that will hopefully provide a text for people to flame instead of just messages in the list. Thanks, Reinaldo >=20 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Saturday, May 27, 2006 3:30 PM > To: Stastny Richard; Otmar Lendl > Cc: speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > Enum? When I dial (650) 453 2312, what is there to resolve _inside_ the > wireless network that owns this number apart from the location of the > user? >=20 > Now, in the scenario where an external call (for example, a cingular > customer calling a Verizon customer (which owns an original t-mobile > number). How that works today? If you say ENUM I would stand corrected > (and surprised), since LNP has been fully deployed since 2003. >=20 > When a user takes its number with them, I assumed this punches a whole > in the telephone prefix hierarchy and a specific entry somewhere is > needed. >=20 > Regards, >=20 > Reinaldo >=20 >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Saturday, May 27, 2006 4:26 AM > > To: Reinaldo Penno; Otmar Lendl > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > >I wonder how > > >LNP is solved within wireless...A specific entry for each phone? That > > >would be crazy. > > > > Ahem, ENUM? > > > > I thought that is all what ENUM is about? > > > > Richard > > > > > > ________________________________ > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > Gesendet: Sa 27.05.2006 11:04 > > An: Otmar Lendl; Patrick Melampy > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > > > > > Hello, > > > > I believe the crux of the problem was missed. > > > > The issue is not really the number of domains. We have today some > > 400.000.000 million hosts on the Internet. BGP peers to do not > exchange > > 400.000.000 million routes, they exchange in the low hundreds of > > thousands. > > > > And why is that? (I guess you know where I'm getting at). That's > because > > IP addresses lend themselves very well to hierarchical deployment, > > compression through prefix/CIDR usage and the like. DNS names are > > strings and hence difficult to come up with a similar scheme. > > > > > > I believe that if domains need to be exchanged between peers: > > > > 1 - Just a limited set would be exchanged and a "default layer 5 > route" > > (equivalent to a traditional default route) would be used. > > > > 2 - Compression schemes like *.company.com, regular expressions or the > > like would need to be used. Having specific routes to AORs would be > > hairy (maybe for the eventual roaming or visiting user). I wonder how > > LNP is solved within wireless...A specific entry for each phone? That > > would be crazy. > > > > 3 - Some new scheme that will make somebody rich....until then.. > > > > I believe subscriptions would be used to exchange mostly "cost" and > > policy information and some domains. I use cost here in the layer 3 > > sense (number of calls, jitter, whatever). Cost would be an abstract > > value or a more specific one (up to the administrator). > > > > Regards, > > > > Reinaldo > > > > > -----Original Message----- > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > Sent: Saturday, May 27, 2006 1:29 AM > > > To: Patrick Melampy > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > > > > > > On 2006/05/26 18:05, Patrick Melampy > wrote: > > > > I suppose like in any distributed routing protocol, there are some > > > chicken > > > > an egg issues. But consider the following. > > > > > > > > PREREQUISITES: > > > > 1.) You know the destination DOMAIN from either ENUM or other > means. > > > > > > [...] > > > > > > > > This technique is very similar to TRIP, only its for DOMAINS and > not > > > partial > > > > E.164 numbers. > > > > > > [...] > > > > > > > Obviously, the data set could get large, as the list of domains > can > > be > > > > really big. There are some possibilities here... > > > > > > Let's do a quick estimate on the number of domains involved: > > > > > > Right now, operators usually give customers URIs of the form > > > @. As long as this is the state of affairs, > > > we're fine as the number of providers is quite finite (a few > > > thousands, perhaps). > > > > > > This is like the state of affairs with respect to email, anno 1990. > > > Back then customers started to notice that if they use their own > > domain > > > for email, then they can switch providers without having to change > > > their email address. Thus a *lot* of people opted to use their > > > own domain for email. > > > > > > My guess is that the same will happen to SIP. Once customers print > > > their SIP uris on business cards, they will want to use their own > > > domains. If providers won't support that feature then I suspect that > > > the regulators will step in and mandate an URI portability solution > > > just as they did in the PSTN with respect to numbers from number > > blocks. > > > (This could get really nasty protocol-wise, so I guess using > customer- > > > owned domains is the far better and likelier solution to the porting > > > question.) > > > > > > So: Anything we come up with here in SPEERMINT needs to cope with a > > > scenario where the use of customer domains in SIP URIs is just as > > > widespread as it is for email. > > > > > > How many domains are used for email? That's hard to say. There are > > > about 60 million gTLD domains and probably more than 20 ccTLD ones. > > > Assuming that only a tenth of that is used for email we're at > > > 8 million domains. Given the exponential growth any system which > > > doesn't scale to at least 10 million domains will be obsolete before > > > the ink is dry on the RFC. > > > > > > So what happens if we do some sort of BGP or TRIP with domains? > > > > > > Let's say we need at least 100 bytes of state information per > domain. > > > That makes a full routing table 1 GB worth of data. That also means > > > that a new border element needs to exchange that amount of data > > > with its peers before it has learned the current state of the > > > routing table. > > > > > > That is some serious amount of data. > > > > > > > 1.) Have notification point to a published document, and the > > document > > > lists > > > > all of the relevant reachability in real time. Thus any change to > > the > > > > document would generate a NOTIFICATION. > > > > > > + a download of up to 1 GB per peer. > > > > > > > 2.) User partial domains, broken up by the "dots". This may allow > > some > > > > wildcarding to reduce the number of domains. For instance, a > carrier > > > like > > > > Verizon may have many 100's of domains attached to it, and version > > is > > > > willing to route and manage SIP traffic to any of them. The NOTIFY > > could > > > > contain something like: Verizon.com or *.verizon.com to indicate > > that > > > any > > > > domain in Verizon is reachable. > > > > > > That's helpful if a provider uses subdomains for internal purposes, > > > but that won't help you with customer owned domains. > > > > > > > This technique may work -- and fit nicely into an existing > protocol. > > All > > > we > > > > would need to do is define the data models (XML?) and or documents > > for > > > > exchanging. > > > > > > I think this technique can work -- if you add an aggregation step > > > before the routing scheme. > > > > > > Take another look at BGP: there you have the concept of an > > > Autonomous System and not only that of prefixes. Maybe you need > > > something similar. > > > > > > One approach to cope with hosted SIP domains could be to use the > > > hostnames as found in SRV records. E.g. for settings like > > > > > > _sip._tcp.customer.domain IN SRV 10 10 5060 sip.provider.com > > > > > > run the routing algorithm on "sip.provider.com" instead > > > of "customer.domain". > > > > > > Another option is to store some AS-equivalent in the customer domain > > > and have the routing algorithm operate on that. In my domain-policy > > > framework this could be expressed e.g. like > > > > > > customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > stating that this domain can be reached using the Speermint routing > > > logic by using the learned route to RoutingID 1042. > > > > > > Or, even better, use non-terminals, and thus refer to the ingress > > > policy stored in the provider's domain: > > > > > > customers.domain IN NAPTR "" 10 10 "D2P+SIP" "" provider.com > > > > > > provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > (+ whatever other facts provider.com wants to announce about his > > > reachability.) > > > > > > This combination of our ideas can indeed work and scale to an > > > unlimited number of customer-owned domains. > > > > > > /ol > > > -- > > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon May 29 18:04:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkpq4-0000gx-Ti; Mon, 29 May 2006 18:03:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkpq3-0000gs-Je for speermint@ietf.org; Mon, 29 May 2006 18:03:51 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkpq1-0006qK-Un for speermint@ietf.org; Mon, 29 May 2006 18:03:51 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-36.mclnva23.covad.net [68.165.240.36]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k4TM47Ld005358 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 29 May 2006 15:04:11 -0700 From: "Richard Shockey" To: "'Francois D. Menard'" , "'Nieminen Klaus'" , Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Mon, 29 May 2006 18:03:35 -0400 Message-ID: <00f801c6836b$becaf830$24f0a544@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <006401c68326$350231d0$8b02a8c0@gestionfm> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIAEEYoMAAEs7nCAACcsIAAAF4UfQAOV3R4AAcK35gAGOKOowAlM1CAABEhoIA= X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.1 (/) X-Scan-Signature: 75ac86d24bd0a3cd8a26e327ae61143e Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1144823315==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============1144823315== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F9_01C6834A.37B95830" This is a multi-part message in MIME format. ------=_NextPart_000_00F9_01C6834A.37B95830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 You might think that and Alan Johnston did some work on this in SIPPING = but it seems no one cares=85plus there are real issues of wether OSP can = scale to the number of transactions necessary to support this kind of thing. =20 Boys and Girls =85 in case you had not heard transaction pricing for = voice is not all that popular among consumers these days. =20 Transaction or distance based pricing for communications has not been popular since the establishment of the penny post in the UK in the = 1800=92s. =20 =20 http://www.dtc.umn.edu/~odlyzko/doc/history.communications0.pdf =20 =20 BTW Content is not king. =20 =20 http://firstmonday.org/issues/issue6_2/odlyzko/ =20 =20 =20 _____ =20 From: Francois D. Menard [mailto:fmenard@xittelecom.com]=20 Sent: Monday, May 29, 2006 9:46 AM To: 'Nieminen Klaus'; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture =20 Klaus, =20 I've always thought we could put some Open Settlement Protocol XML data = in a SIP invite. =20 F. =20 -- Fran=E7ois D. M=E9nard Charg=E9 de projet Xit t=E9l=E9com inc. 1350 rue Royale #800 Trois-Rivi=E8res, QC, G9A 4J4 Canada fmenard@xittelecom.com Tel: (819) 374-2556 ext. 268 Fax: (819) 374-0395 Cell: (819) 692-1383 =20 =20 ------=_NextPart_000_00F9_01C6834A.37B95830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Speermint] Updated Draft: SPEERMINT Peering = Architecture

 

 

You might think that and Alan = Johnston did some work on this in SIPPING but it seems no one cares…plus there = are real issues of wether OSP can scale to the number of transactions = necessary to support this kind of thing.

 

Boys and Girls … in case you = had not heard transaction pricing for voice is not all that popular among = consumers these days.

 

Transaction or distance based = pricing for communications has not been popular since the establishment of the penny = post in the UK in the 1800’s.

 

 

= http://www.dtc.umn.edu/~odlyzko/doc/history.communications0.pdf<= /o:p>

 

 

BTW Content is not = king.

 

 

http://firstmond= ay.org/issues/issue6_2/odlyzko/

 

 

 

From: = Francois D. Menard [mailto:fmenard@xittelecom.com]
Sent: Monday, May 29, = 2006 9:46 AM
To: 'Nieminen Klaus'; speermint@ietf.org
Subject: RE: [Speermint] = Updated Draft: SPEERMINT Peering Architecture

 

Klaus,

 

I've always thought we could put = some Open Settlement Protocol XML data in a SIP = invite.

 

F.

 

--

Fran=E7ois D. M=E9nard

Charg=E9 de projet

Xit t=E9l=E9com inc.

1350 rue Royale #800

Trois-Rivi=E8res, QC, G9A = 4J4

Canada

fmenard@xittelecom.com<= /font>

Tel: (819) 374-2556 ext. = 268

Fax: (819) 374-0395

Cell: (819) 692-1383

 

 

------=_NextPart_000_00F9_01C6834A.37B95830-- --===============1144823315== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============1144823315==-- From speermint-bounces@ietf.org Mon May 29 18:07:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkpt0-0001uw-MT; Mon, 29 May 2006 18:06:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkpsz-0001ur-K2 for speermint@ietf.org; Mon, 29 May 2006 18:06:53 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkpsy-00070G-80 for speermint@ietf.org; Mon, 29 May 2006 18:06:53 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-36.mclnva23.covad.net [68.165.240.36]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k4TM77u4005829 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 29 May 2006 15:07:08 -0700 From: "Richard Shockey" To: "'Khan, Sohel Q [CTO]'" , "'Stastny Richard'" , "'Reinaldo Penno'" Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Mon, 29 May 2006 18:06:35 -0400 Message-ID: <010001c6836c$27d820a0$24f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <2f5e01c68211$930d0637$664ad60a@ad.sprint.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIAEEYoMAAEs7nCAACcsIAAAF4UfQAOV3R4AFaefXA= X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org You might think that but ..I couldn't possibly comment. :-) > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: Sunday, May 28, 2006 12:48 AM > To: Stastny Richard; Reinaldo Penno > Cc: speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > I think issues of mobility and number portability need to be addressed > together in SPEERMINT LF. > > Sohel Khan, Ph.D. > Sprint-Nextel > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon May 29 18:28:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkqDf-0008By-3X; Mon, 29 May 2006 18:28:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkqDd-0008Bl-Fy for speermint@ietf.org; Mon, 29 May 2006 18:28:13 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkprq-0006u9-34 for speermint@ietf.org; Mon, 29 May 2006 18:05:42 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fkpgt-0003mk-Rd for speermint@ietf.org; Mon, 29 May 2006 17:54:26 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-36.mclnva23.covad.net [68.165.240.36]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k4TLsgwr004480 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 29 May 2006 14:54:44 -0700 From: "Richard Shockey" To: "'Khan, Sohel Q [CTO]'" , "'Stastny Richard'" Subject: RE: [Speermint] Defining Location Function (RE: Updated Draft:SPEERMINT Peering Architecture) Date: Mon, 29 May 2006 17:54:10 -0400 Message-ID: <00f401c6836a$6c27fd90$24f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <978886E57CC1D64EAFAC157B98E36F9E091599CE@PLSWB08C.ad.sprint.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIAEEYoMAAEs7nCAACcsIAAAF4UfQAOV3R4AAcK35gAP5z0YAAA2P8gAAgEsSAABqXeoA== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: -2.6 (--) X-Scan-Signature: ebd5ffc455fd7bcccba963126e1cf1f5 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org NO .. that was called TRIP ( go do a RFC search) and no one in their right mind wants to put a BGB like layer on VoIP routing. > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: Monday, May 29, 2006 2:56 PM > To: Stastny Richard > Cc: speermint@ietf.org > Subject: [Speermint] Defining Location Function (RE: Updated > Draft:SPEERMINT Peering Architecture) > > > Is it possible to take lessons from hierarchical eBGP routing? > We can consider each provider as the Autonomous System (say Level 0), a > federation is a hierarchical Autonomous system (say Level 1) that > contains a group of Autonomous-system (level 0). Hierarchical > Autonomous system's (Level 1) SIP route-database (as opposed to the BGP > routing table) is the Location Function (LF). SIP call routing feature > will be destination-based, path-vector based, and policy based similar > to BGP features. > I am trying to initiate a discussion in a different angle. > > Thanks, > > Sohel Khan, Ph.D. > Technology Strategist > Sprint-Nextel > 913-794-1470 (office) > 913-486-3145 (cell) > > > > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Monday, May 29, 2006 10:06 AM > To: Khan, Sohel Q [CTO] > Cc: speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > Sohel, > > I posted this already on Friday, but I think everybody (including me) > lost track already;-) > > So here once again: > > "May I try my summary: the Location function is a process containing > eventually more then one step: > > "If you start with the CRD (e.g a SIP AoR entered by the User or derived > from ENUM)" > > Remark: Whith this I ment that the E.164 to SIP URI mapping is already > done, because this is out-of-scope of SPEERMINT. > In addition, SPEERMINT MUST be able to work in the same way if the user > has entered a SIP URI direct. This is why I prefer that the result of an > ENUM query is an AoR and not directly the ingress element to the > destination network. > > > "1. The AoR gives you the destination network > > 2. You need to locate the peering club (= federation) for exchanging SIP > messages (L5 )with the destination network > > 3. so you need to locate the policy you want to use and make a decision > on the federation > (note: a destination network may belong to more then one federations)" > (Remark: both origination network and destination network may be members > of more then one federation. They may need to locate a common one. If > more then one federation is in common, it is the choice of the > origination network to select one - So the Policy Function is embedded > in the LF) > > 4. "having chosen a federation, you need to locate the ingress > proxy(ies) the destination network is using within this federation. > > 5. If you are using a separate peering for exchanging media, you now may > locate these" > > Additional remark: In step 4. and 5. some geographic location magic > could come into play as requested by some on this list. > > Regards > Richard > > > -----Original Message----- > > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > Sent: Monday, May 29, 2006 4:30 PM > > To: Stastny Richard > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > Richard, > > > > Would you please describe what LF should perform (in your opinion)? > > > > > > Thanks, > > > > Sohel > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Sunday, May 28, 2006 3:07 AM > > To: Khan, Sohel Q [CTO] > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > I do not know how often I stated here that numbering issues (and > > therefore also NUMBER Portability issues) are out-of-scope in > SPEERMINT > > > > So NUMBER Portablility cannot ne addressed in SPEERMINT LF > > > > Or we change the SPEERMINT charter > > > > Richard > > > > ________________________________ > > > > Von: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > Gesendet: So 28.05.2006 06:48 > > An: Stastny Richard; Reinaldo Penno > > Cc: speermint@ietf.org > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > > > > > I think issues of mobility and number portability need to be addressed > > > together in SPEERMINT LF. > > > > Sohel Khan, Ph.D. > > Sprint-Nextel > > > > -----Original Message----- > > From: "Stastny Richard" > > To: "Reinaldo Penno" > > Cc: "speermint@ietf.org" > > Sent: 5/27/06 4:52 PM > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > What question? > > Richard > > > > ________________________________ > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > Gesendet: Sa 27.05.2006 23:46 > > An: Stastny Richard > > Cc: speermint@ietf.org > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > > > > > Apart form your outside-of-the-us rhetoric the questions remains. > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Saturday, May 27, 2006 2:38 PM > > > To: Reinaldo Penno > > > Cc: speermint@ietf.org > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > > > > > > ENUM issues should not be discussed in SPEERMINT, just some > questions > > > > > > >Enum? When I dial (650) 453 2312, what is there to resolve _inside_ > > the > > > >wireless network that owns this number apart from the location of > the > > > > > >user? > > > > > > and _outside_? > > > ENUM is about numbers like +16504532312 > > > > > > hello, we are talking E.164 numbers in ENUM, which is international > > > numbers > > > > > > >Now, in the scenario where an external call (for example, a > cingular > > > >customer calling a Verizon customer (which owns an original > t-mobile > > > >number). How that works today? If you say ENUM I would stand > > corrected > > > >(and surprised), since LNP has been fully deployed since 2003. > > > > > > Cingular?Verizon? ... > > > > > > we are talking about a global solution here You are a bit US centric > > > > here, there is also some 200 other nations ozt there. > > > > > > I have no access to the US LNP database from e.g. Austria > > > > > > So you want to consider US national databases only in speermint? > > > > > > Richard > > > > > > > > > > > > ________________________________ > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Gesendet: Sa 27.05.2006 21:30 > > > An: Stastny Richard; Otmar Lendl > > > Cc: speermint@ietf.org > > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > > > > > > > > > > > > Enum? When I dial (650) 453 2312, what is there to resolve _inside_ > > the > > > wireless network that owns this number apart from the location of > the > > > user? > > > > > > > > > Now, in the scenario where an external call (for example, a cingular > > > > customer calling a Verizon customer (which owns an original t-mobile > > > > number). How that works today? If you say ENUM I would stand > corrected > > > > > (and surprised), since LNP has been fully deployed since 2003. > > > > > > When a user takes its number with them, I assumed this punches a > whole > > > > > in the telephone prefix hierarchy and a specific entry somewhere is > > > needed. > > > > > > Regards, > > > > > > Reinaldo > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Saturday, May 27, 2006 4:26 AM > > > > To: Reinaldo Penno; Otmar Lendl > > > > Cc: speermint@ietf.org > > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > > Architecture > > > > > > > > >I wonder how > > > > >LNP is solved within wireless...A specific entry for each phone? > > That > > > > >would be crazy. > > > > > > > > Ahem, ENUM? > > > > > > > > I thought that is all what ENUM is about? > > > > > > > > Richard > > > > > > > > > > > > ________________________________ > > > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > Gesendet: Sa 27.05.2006 11:04 > > > > An: Otmar Lendl; Patrick Melampy > > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org > > > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering > > Architecture > > > > > > > > > > > > > > > > Hello, > > > > > > > > I believe the crux of the problem was missed. > > > > > > > > The issue is not really the number of domains. We have today some > > > > 400.000.000 million hosts on the Internet. BGP peers to do not > > > exchange > > > > 400.000.000 million routes, they exchange in the low hundreds of > > > > thousands. > > > > > > > > And why is that? (I guess you know where I'm getting at). That's > > > because > > > > IP addresses lend themselves very well to hierarchical deployment, > > > > > compression through prefix/CIDR usage and the like. DNS names are > > > > strings and hence difficult to come up with a similar scheme. > > > > > > > > > > > > I believe that if domains need to be exchanged between peers: > > > > > > > > 1 - Just a limited set would be exchanged and a "default layer 5 > > > route" > > > > (equivalent to a traditional default route) would be used. > > > > > > > > 2 - Compression schemes like *.company.com, regular expressions or > > the > > > > like would need to be used. Having specific routes to AORs would > be > > > > hairy (maybe for the eventual roaming or visiting user). I wonder > > how > > > > LNP is solved within wireless...A specific entry for each phone? > > That > > > > would be crazy. > > > > > > > > 3 - Some new scheme that will make somebody rich....until then.. > > > > > > > > I believe subscriptions would be used to exchange mostly "cost" > and > > > > policy information and some domains. I use cost here in the layer > 3 > > > > sense (number of calls, jitter, whatever). Cost would be an > abstract > > > > > > value or a more specific one (up to the administrator). > > > > > > > > Regards, > > > > > > > > Reinaldo > > > > > > > > > -----Original Message----- > > > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > > > Sent: Saturday, May 27, 2006 1:29 AM > > > > > To: Patrick Melampy > > > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > > > Architecture > > > > > > > > > > On 2006/05/26 18:05, Patrick Melampy > > > wrote: > > > > > > I suppose like in any distributed routing protocol, there are > > some > > > > > chicken > > > > > > an egg issues. But consider the following. > > > > > > > > > > > > PREREQUISITES: > > > > > > 1.) You know the destination DOMAIN from either ENUM or other > > > means. > > > > > > > > > > [...] > > > > > > > > > > > > This technique is very similar to TRIP, only its for DOMAINS > and > > > not > > > > > partial > > > > > > E.164 numbers. > > > > > > > > > > [...] > > > > > > > > > > > Obviously, the data set could get large, as the list of > domains > > > can > > > > be > > > > > > really big. There are some possibilities here... > > > > > > > > > > Let's do a quick estimate on the number of domains involved: > > > > > > > > > > Right now, operators usually give customers URIs of the form > > > > > @. As long as this is the state of > > affairs, > > > > > we're fine as the number of providers is quite finite (a few > > > > > thousands, perhaps). > > > > > > > > > > This is like the state of affairs with respect to email, anno > > 1990. > > > > > Back then customers started to notice that if they use their own > > > > domain > > > > > for email, then they can switch providers without having to > change > > > > > > > their email address. Thus a *lot* of people opted to use their > own > > > > > > > domain for email. > > > > > > > > > > My guess is that the same will happen to SIP. Once customers > print > > > > > > > their SIP uris on business cards, they will want to use their > own > > > > > domains. If providers won't support that feature then I suspect > > that > > > > > the regulators will step in and mandate an URI portability > > solution > > > > > just as they did in the PSTN with respect to numbers from number > > > > blocks. > > > > > (This could get really nasty protocol-wise, so I guess using > > > customer- > > > > > owned domains is the far better and likelier solution to the > > porting > > > > > question.) > > > > > > > > > > So: Anything we come up with here in SPEERMINT needs to cope > with > > a > > > > > scenario where the use of customer domains in SIP URIs is just > as > > > > > widespread as it is for email. > > > > > > > > > > How many domains are used for email? That's hard to say. There > are > > > > > > > about 60 million gTLD domains and probably more than 20 ccTLD > > ones. > > > > > Assuming that only a tenth of that is used for email we're at > > > > > 8 million domains. Given the exponential growth any system which > > > > > > doesn't scale to at least 10 million domains will be obsolete > > before > > > > > the ink is dry on the RFC. > > > > > > > > > > So what happens if we do some sort of BGP or TRIP with domains? > > > > > > > > > > Let's say we need at least 100 bytes of state information per > > > domain. > > > > > That makes a full routing table 1 GB worth of data. That also > > means > > > > > that a new border element needs to exchange that amount of data > > > > > with its peers before it has learned the current state of the > > > > > routing table. > > > > > > > > > > That is some serious amount of data. > > > > > > > > > > > 1.) Have notification point to a published document, and the > > > > document > > > > > lists > > > > > > all of the relevant reachability in real time. Thus any change > > to > > > > the > > > > > > document would generate a NOTIFICATION. > > > > > > > > > > + a download of up to 1 GB per peer. > > > > > > > > > > > 2.) User partial domains, broken up by the "dots". This may > > allow > > > > some > > > > > > wildcarding to reduce the number of domains. For instance, a > > > carrier > > > > > like > > > > > > Verizon may have many 100's of domains attached to it, and > > version > > > > is > > > > > > willing to route and manage SIP traffic to any of them. The > > NOTIFY > > > > could > > > > > > contain something like: Verizon.com or *.verizon.com to > indicate > > > > that > > > > > any > > > > > > domain in Verizon is reachable. > > > > > > > > > > That's helpful if a provider uses subdomains for internal > > purposes, > > > > > but that won't help you with customer owned domains. > > > > > > > > > > > This technique may work -- and fit nicely into an existing > > > protocol. > > > > All > > > > > we > > > > > > would need to do is define the data models (XML?) and or > > documents > > > > for > > > > > > exchanging. > > > > > > > > > > I think this technique can work -- if you add an aggregation > step > > > > > before the routing scheme. > > > > > > > > > > Take another look at BGP: there you have the concept of an > > > > > Autonomous System and not only that of prefixes. Maybe you need > > > > > something similar. > > > > > > > > > > One approach to cope with hosted SIP domains could be to use the > > > > > > hostnames as found in SRV records. E.g. for settings like > > > > > > > > > > _sip._tcp.customer.domain IN SRV 10 10 5060 sip.provider.com > > > > > > > > > > run the routing algorithm on "sip.provider.com" instead of > > > > > "customer.domain". > > > > > > > > > > Another option is to store some AS-equivalent in the customer > > domain > > > > > and have the routing algorithm operate on that. In my > > domain-policy > > > > > framework this could be expressed e.g. like > > > > > > > > > > customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > > > > > stating that this domain can be reached using the Speermint > > routing > > > > > logic by using the learned route to RoutingID 1042. > > > > > > > > > > Or, even better, use non-terminals, and thus refer to the > ingress > > > > > policy stored in the provider's domain: > > > > > > > > > > customers.domain IN NAPTR "" 10 10 "D2P+SIP" "" provider.com > > > > > > > > > > provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > > > > > (+ whatever other facts provider.com wants to announce about his > > > > > reachability.) > > > > > > > > > > This combination of our ideas can indeed work and scale to an > > > > > unlimited number of customer-owned domains. > > > > > > > > > > /ol > > > > > -- > > > > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon May 29 20:31:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fks8V-00064E-Mj; Mon, 29 May 2006 20:31:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fks7v-0005u2-MP for speermint@ietf.org; Mon, 29 May 2006 20:30:27 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fks4U-0004F2-CQ for speermint@ietf.org; Mon, 29 May 2006 20:26:55 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 29 May 2006 17:26:53 -0700 X-IronPort-AV: i="4.05,186,1146466800"; d="scan'208"; a="554563879:sNHT56115428" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Defining Location Function (RE: UpdatedDraft:SPEERMINT Peering Architecture) Date: Mon, 29 May 2006 20:26:51 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804652EA4@proton.jnpr.net> In-Reply-To: <00f401c6836a$6c27fd90$24f0a544@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Defining Location Function (RE: UpdatedDraft:SPEERMINT Peering Architecture) Thread-Index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIAEEYoMAAEs7nCAACcsIAAAF4UfQAOV3R4AAcK35gAP5z0YAAA2P8gAAgEsSAABqXeoAAE631g From: "Reinaldo Penno" To: , "Khan, Sohel Q [CTO]" , "Stastny Richard" X-Spam-Score: 0.0 (/) X-Scan-Signature: 04ebe73024b6be81174765e91aced811 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Sohel, I believe a VoIP-VoIP call have several stages: 1. Location How do I (domain A) discover where the proxy (which could be the final one) to cross into domain B? There can be more than one in a certain location and even geographically dispersed locations. 1.1 Policy exchange I In determining domain's B crossing point, a policy query/exchange might happen. This might come in the form of DNS, a lookup on SUBSCRIPTION data or both 2. Membership After I discover domain's B proxy how to establish peering? Is it already established? Is it a federation? This is what I call membership process. 3. Policy exchange II In a certain location where domain A and B peer, domain A's proxy might perform (another) policy exchange/query to find out which of domain's B several proxies is the best suited at that point in time.=20 4. Call establishment Call gets established. 5. Media Media goes probably through the same path being marked according to the peering fabric's dscp. Regards, Reinaldo > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Monday, May 29, 2006 2:54 PM > To: 'Khan, Sohel Q [CTO]'; 'Stastny Richard' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Defining Location Function (RE: > UpdatedDraft:SPEERMINT Peering Architecture) >=20 >=20 > NO .. that was called TRIP ( go do a RFC search) and no one in their right > mind wants to put a BGB like layer on VoIP routing. >=20 >=20 >=20 > > -----Original Message----- > > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > Sent: Monday, May 29, 2006 2:56 PM > > To: Stastny Richard > > Cc: speermint@ietf.org > > Subject: [Speermint] Defining Location Function (RE: Updated > > Draft:SPEERMINT Peering Architecture) > > > > > > Is it possible to take lessons from hierarchical eBGP routing? > > We can consider each provider as the Autonomous System (say Level 0), a > > federation is a hierarchical Autonomous system (say Level 1) that > > contains a group of Autonomous-system (level 0). Hierarchical > > Autonomous system's (Level 1) SIP route-database (as opposed to the BGP > > routing table) is the Location Function (LF). SIP call routing feature > > will be destination-based, path-vector based, and policy based similar > > to BGP features. > > I am trying to initiate a discussion in a different angle. > > > > Thanks, > > > > Sohel Khan, Ph.D. > > Technology Strategist > > Sprint-Nextel > > 913-794-1470 (office) > > 913-486-3145 (cell) > > > > > > > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Monday, May 29, 2006 10:06 AM > > To: Khan, Sohel Q [CTO] > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > Sohel, > > > > I posted this already on Friday, but I think everybody (including me) > > lost track already;-) > > > > So here once again: > > > > "May I try my summary: the Location function is a process containing > > eventually more then one step: > > > > "If you start with the CRD (e.g a SIP AoR entered by the User or derived > > from ENUM)" > > > > Remark: Whith this I ment that the E.164 to SIP URI mapping is already > > done, because this is out-of-scope of SPEERMINT. > > In addition, SPEERMINT MUST be able to work in the same way if the user > > has entered a SIP URI direct. This is why I prefer that the result of an > > ENUM query is an AoR and not directly the ingress element to the > > destination network. > > > > > > "1. The AoR gives you the destination network > > > > 2. You need to locate the peering club (=3D federation) for = exchanging SIP > > messages (L5 )with the destination network > > > > 3. so you need to locate the policy you want to use and make a decision > > on the federation > > (note: a destination network may belong to more then one federations)" > > (Remark: both origination network and destination network may be members > > of more then one federation. They may need to locate a common one. If > > more then one federation is in common, it is the choice of the > > origination network to select one - So the Policy Function is embedded > > in the LF) > > > > 4. "having chosen a federation, you need to locate the ingress > > proxy(ies) the destination network is using within this federation. > > > > 5. If you are using a separate peering for exchanging media, you now may > > locate these" > > > > Additional remark: In step 4. and 5. some geographic location magic > > could come into play as requested by some on this list. > > > > Regards > > Richard > > > > > -----Original Message----- > > > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > > Sent: Monday, May 29, 2006 4:30 PM > > > To: Stastny Richard > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > > > Richard, > > > > > > Would you please describe what LF should perform (in your opinion)? > > > > > > > > > Thanks, > > > > > > Sohel > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Sunday, May 28, 2006 3:07 AM > > > To: Khan, Sohel Q [CTO] > > > Cc: speermint@ietf.org > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > > > I do not know how often I stated here that numbering issues (and > > > therefore also NUMBER Portability issues) are out-of-scope in > > SPEERMINT > > > > > > So NUMBER Portablility cannot ne addressed in SPEERMINT LF > > > > > > Or we change the SPEERMINT charter > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > > Gesendet: So 28.05.2006 06:48 > > > An: Stastny Richard; Reinaldo Penno > > > Cc: speermint@ietf.org > > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > > > > > > > > > I think issues of mobility and number portability need to be addressed > > > > > together in SPEERMINT LF. > > > > > > Sohel Khan, Ph.D. > > > Sprint-Nextel > > > > > > -----Original Message----- > > > From: "Stastny Richard" > > > To: "Reinaldo Penno" > > > Cc: "speermint@ietf.org" > > > Sent: 5/27/06 4:52 PM > > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > > > What question? > > > Richard > > > > > > ________________________________ > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Gesendet: Sa 27.05.2006 23:46 > > > An: Stastny Richard > > > Cc: speermint@ietf.org > > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > > > > > > > > > Apart form your outside-of-the-us rhetoric the questions remains. > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Saturday, May 27, 2006 2:38 PM > > > > To: Reinaldo Penno > > > > Cc: speermint@ietf.org > > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > > Architecture > > > > > > > > ENUM issues should not be discussed in SPEERMINT, just some > > questions > > > > > > > > >Enum? When I dial (650) 453 2312, what is there to resolve _inside_ > > > the > > > > >wireless network that owns this number apart from the location of > > the > > > > > > > >user? > > > > > > > > and _outside_? > > > > ENUM is about numbers like +16504532312 > > > > > > > > hello, we are talking E.164 numbers in ENUM, which is international > > > > numbers > > > > > > > > >Now, in the scenario where an external call (for example, a > > cingular > > > > >customer calling a Verizon customer (which owns an original > > t-mobile > > > > >number). How that works today? If you say ENUM I would stand > > > corrected > > > > >(and surprised), since LNP has been fully deployed since 2003. > > > > > > > > Cingular?Verizon? ... > > > > > > > > we are talking about a global solution here You are a bit US centric > > > > > > here, there is also some 200 other nations ozt there. > > > > > > > > I have no access to the US LNP database from e.g. Austria > > > > > > > > So you want to consider US national databases only in speermint? > > > > > > > > Richard > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > Gesendet: Sa 27.05.2006 21:30 > > > > An: Stastny Richard; Otmar Lendl > > > > Cc: speermint@ietf.org > > > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering > > Architecture > > > > > > > > > > > > > > > > Enum? When I dial (650) 453 2312, what is there to resolve _inside_ > > > the > > > > wireless network that owns this number apart from the location of > > the > > > > user? > > > > > > > > > > > > Now, in the scenario where an external call (for example, a cingular > > > > > > customer calling a Verizon customer (which owns an original t-mobile > > > > > > number). How that works today? If you say ENUM I would stand > > corrected > > > > > > > (and surprised), since LNP has been fully deployed since 2003. > > > > > > > > When a user takes its number with them, I assumed this punches a > > whole > > > > > > > in the telephone prefix hierarchy and a specific entry somewhere is > > > > needed. > > > > > > > > Regards, > > > > > > > > Reinaldo > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Saturday, May 27, 2006 4:26 AM > > > > > To: Reinaldo Penno; Otmar Lendl > > > > > Cc: speermint@ietf.org > > > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > > > Architecture > > > > > > > > > > >I wonder how > > > > > >LNP is solved within wireless...A specific entry for each phone? > > > That > > > > > >would be crazy. > > > > > > > > > > Ahem, ENUM? > > > > > > > > > > I thought that is all what ENUM is about? > > > > > > > > > > Richard > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > Gesendet: Sa 27.05.2006 11:04 > > > > > An: Otmar Lendl; Patrick Melampy > > > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org > > > > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering > > > Architecture > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > I believe the crux of the problem was missed. > > > > > > > > > > The issue is not really the number of domains. We have today some > > > > > 400.000.000 million hosts on the Internet. BGP peers to do not > > > > exchange > > > > > 400.000.000 million routes, they exchange in the low hundreds of > > > > > thousands. > > > > > > > > > > And why is that? (I guess you know where I'm getting at). That's > > > > because > > > > > IP addresses lend themselves very well to hierarchical deployment, > > > > > > > compression through prefix/CIDR usage and the like. DNS names are > > > > > strings and hence difficult to come up with a similar scheme. > > > > > > > > > > > > > > > I believe that if domains need to be exchanged between peers: > > > > > > > > > > 1 - Just a limited set would be exchanged and a "default layer 5 > > > > route" > > > > > (equivalent to a traditional default route) would be used. > > > > > > > > > > 2 - Compression schemes like *.company.com, regular expressions or > > > the > > > > > like would need to be used. Having specific routes to AORs would > > be > > > > > hairy (maybe for the eventual roaming or visiting user). I wonder > > > how > > > > > LNP is solved within wireless...A specific entry for each phone? > > > That > > > > > would be crazy. > > > > > > > > > > 3 - Some new scheme that will make somebody rich....until then.. > > > > > > > > > > I believe subscriptions would be used to exchange mostly "cost" > > and > > > > > policy information and some domains. I use cost here in the layer > > 3 > > > > > sense (number of calls, jitter, whatever). Cost would be an > > abstract > > > > > > > > value or a more specific one (up to the administrator). > > > > > > > > > > Regards, > > > > > > > > > > Reinaldo > > > > > > > > > > > -----Original Message----- > > > > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > > > > Sent: Saturday, May 27, 2006 1:29 AM > > > > > > To: Patrick Melampy > > > > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > > > > Architecture > > > > > > > > > > > > On 2006/05/26 18:05, Patrick Melampy > > > > wrote: > > > > > > > I suppose like in any distributed routing protocol, there are > > > some > > > > > > chicken > > > > > > > an egg issues. But consider the following. > > > > > > > > > > > > > > PREREQUISITES: > > > > > > > 1.) You know the destination DOMAIN from either ENUM or other > > > > means. > > > > > > > > > > > > [...] > > > > > > > > > > > > > > This technique is very similar to TRIP, only its for DOMAINS > > and > > > > not > > > > > > partial > > > > > > > E.164 numbers. > > > > > > > > > > > > [...] > > > > > > > > > > > > > Obviously, the data set could get large, as the list of > > domains > > > > can > > > > > be > > > > > > > really big. There are some possibilities here... > > > > > > > > > > > > Let's do a quick estimate on the number of domains involved: > > > > > > > > > > > > Right now, operators usually give customers URIs of the form > > > > > > @. As long as this is the state of > > > affairs, > > > > > > we're fine as the number of providers is quite finite (a few > > > > > > thousands, perhaps). > > > > > > > > > > > > This is like the state of affairs with respect to email, anno > > > 1990. > > > > > > Back then customers started to notice that if they use their own > > > > > domain > > > > > > for email, then they can switch providers without having to > > change > > > > > > > > > their email address. Thus a *lot* of people opted to use their > > own > > > > > > > > > domain for email. > > > > > > > > > > > > My guess is that the same will happen to SIP. Once customers > > print > > > > > > > > > their SIP uris on business cards, they will want to use their > > own > > > > > > domains. If providers won't support that feature then I suspect > > > that > > > > > > the regulators will step in and mandate an URI portability > > > solution > > > > > > just as they did in the PSTN with respect to numbers from number > > > > > blocks. > > > > > > (This could get really nasty protocol-wise, so I guess using > > > > customer- > > > > > > owned domains is the far better and likelier solution to the > > > porting > > > > > > question.) > > > > > > > > > > > > So: Anything we come up with here in SPEERMINT needs to cope > > with > > > a > > > > > > scenario where the use of customer domains in SIP URIs is just > > as > > > > > > widespread as it is for email. > > > > > > > > > > > > How many domains are used for email? That's hard to say. There > > are > > > > > > > > > about 60 million gTLD domains and probably more than 20 ccTLD > > > ones. > > > > > > Assuming that only a tenth of that is used for email we're at > > > > > > 8 million domains. Given the exponential growth any system which > > > > > > > > doesn't scale to at least 10 million domains will be obsolete > > > before > > > > > > the ink is dry on the RFC. > > > > > > > > > > > > So what happens if we do some sort of BGP or TRIP with domains? > > > > > > > > > > > > Let's say we need at least 100 bytes of state information per > > > > domain. > > > > > > That makes a full routing table 1 GB worth of data. That also > > > means > > > > > > that a new border element needs to exchange that amount of data > > > > > > with its peers before it has learned the current state of the > > > > > > routing table. > > > > > > > > > > > > That is some serious amount of data. > > > > > > > > > > > > > 1.) Have notification point to a published document, and the > > > > > document > > > > > > lists > > > > > > > all of the relevant reachability in real time. Thus any change > > > to > > > > > the > > > > > > > document would generate a NOTIFICATION. > > > > > > > > > > > > + a download of up to 1 GB per peer. > > > > > > > > > > > > > 2.) User partial domains, broken up by the "dots". This may > > > allow > > > > > some > > > > > > > wildcarding to reduce the number of domains. For instance, a > > > > carrier > > > > > > like > > > > > > > Verizon may have many 100's of domains attached to it, and > > > version > > > > > is > > > > > > > willing to route and manage SIP traffic to any of them. The > > > NOTIFY > > > > > could > > > > > > > contain something like: Verizon.com or *.verizon.com to > > indicate > > > > > that > > > > > > any > > > > > > > domain in Verizon is reachable. > > > > > > > > > > > > That's helpful if a provider uses subdomains for internal > > > purposes, > > > > > > but that won't help you with customer owned domains. > > > > > > > > > > > > > This technique may work -- and fit nicely into an existing > > > > protocol. > > > > > All > > > > > > we > > > > > > > would need to do is define the data models (XML?) and or > > > documents > > > > > for > > > > > > > exchanging. > > > > > > > > > > > > I think this technique can work -- if you add an aggregation > > step > > > > > > before the routing scheme. > > > > > > > > > > > > Take another look at BGP: there you have the concept of an > > > > > > Autonomous System and not only that of prefixes. Maybe you need > > > > > > something similar. > > > > > > > > > > > > One approach to cope with hosted SIP domains could be to use the > > > > > > > > hostnames as found in SRV records. E.g. for settings like > > > > > > > > > > > > _sip._tcp.customer.domain IN SRV 10 10 5060 sip.provider.com > > > > > > > > > > > > run the routing algorithm on "sip.provider.com" instead of > > > > > > "customer.domain". > > > > > > > > > > > > Another option is to store some AS-equivalent in the customer > > > domain > > > > > > and have the routing algorithm operate on that. In my > > > domain-policy > > > > > > framework this could be expressed e.g. like > > > > > > > > > > > > customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > > > > > > > stating that this domain can be reached using the Speermint > > > routing > > > > > > logic by using the learned route to RoutingID 1042. > > > > > > > > > > > > Or, even better, use non-terminals, and thus refer to the > > ingress > > > > > > policy stored in the provider's domain: > > > > > > > > > > > > customers.domain IN NAPTR "" 10 10 "D2P+SIP" "" provider.com > > > > > > > > > > > > provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > > > > > > > (+ whatever other facts provider.com wants to announce about his > > > > > > reachability.) > > > > > > > > > > > > This combination of our ideas can indeed work and scale to an > > > > > > unlimited number of customer-owned domains. > > > > > > > > > > > > /ol > > > > > > -- > > > > > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > > > > > > > > > _______________________________________________ > > > > > > Speermint mailing list > > > > > > Speermint@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon May 29 20:32:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FksAC-0006xC-5w; Mon, 29 May 2006 20:32:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fks84-0005wu-3W for speermint@ietf.org; Mon, 29 May 2006 20:30:36 -0400 Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkrux-0003UR-Nq for speermint@ietf.org; Mon, 29 May 2006 20:17:04 -0400 Received: (qmail 20397 invoked by uid 510); 29 May 2006 19:57:09 -0400 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(24.1.140.191):. Processed in 1.055711 secs); 29 May 2006 23:57:09 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(24.1.140.191):. Processed in 1.055711 secs Process 20392) Received: from c-24-1-140-191.hsd1.tx.comcast.net (HELO DSX400) (henry@pulver.com@24.1.140.191) by 192.246.69.184 with SMTP; Mon, 29 May 2006 23:57:08 +0000 From: "Henry Sinnreich" To: , "'Michael Hammer \(mhammer\)'" , "'Otmar Lendl'" Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Mon, 29 May 2006 19:16:57 -0500 Organization: pulver.com Message-ID: <016d01c6837e$5e948ef0$2800a8c0@DSX400> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <00ec01c68281$efb534a0$24f0a544@cis.neustar.com> Thread-Index: AcZ/J15wu/Ba/2sNTLCXUP/3hHYAhQAFEQbgAAESENAA0GL/UAA+jhpg X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: "'Khan, Sohel Q \[CTO\]'" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > Queried or cached it makes no difference. The authors of this paper represent those who think there is a big difference. Reasons include DNS caching conflicts with changing IP addresses, security, etc. http://www.cs.cornell.edu/people/egs/papers/codons-sigcomm.pdf Fee free to dismiss yours humbly, I don't mind, but addressing the arguments in the paper would be more convincing. It would be interesting to learn why the 20 year old DNS 'as is' is considered to be good enough for eternity and any successor technology does not even merit a read, let alone reconsidering business evolution plans based on 1986 technology. Reminds us of SS7 indeed... So what are counter-arguments to those presented in the paper on the Cooperative Domain Name System? Thanks, Henry -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us] Sent: Sunday, May 28, 2006 1:10 PM To: henry@pulver.com; 'Michael Hammer (mhammer)'; 'Otmar Lendl' Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Yes Henry ..but whether we like or not the DNS or at least the technology of DNS is becoming the defacto number translation database of choice and as such heralds the end of SS7. Queried or cached it makes no difference. > -----Original Message----- > From: Henry Sinnreich [mailto:henry@pulver.com] > Sent: Wednesday, May 24, 2006 10:47 AM > To: 'Michael Hammer (mhammer)'; 'Otmar Lendl' > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > I believe Mike is right on track. Overloading the DNS with application > protocol information, such as detailed policies for SIP is not what the > DNS > was designed for. > > Going further down this path would make the DNS a successor of the AIN! > > Thanks, Henry _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon May 29 21:00:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FksaO-00084C-Tx; Mon, 29 May 2006 20:59:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FksaO-000847-A2 for speermint@ietf.org; Mon, 29 May 2006 20:59:52 -0400 Received: from [204.209.140.176] (helo=wodka.aus-biz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FksaM-00008f-Vl for speermint@ietf.org; Mon, 29 May 2006 20:59:52 -0400 Received: from [192.168.1.101] (cpe-24-95-54-117.columbus.res.rr.com [24.95.54.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Duane Groth", Issuer "CAcert Class 3 Root" (not verified)) by wodka.aus-biz.com (Postfix) with ESMTP id 308685A11; Mon, 29 May 2006 20:59:46 -0400 (EDT) Message-ID: <447B98FA.6030703@e164.org> Date: Mon, 29 May 2006 20:59:38 -0400 From: Duane User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: henry@pulver.com, speermint@ietf.org Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture References: <016d01c6837e$5e948ef0$2800a8c0@DSX400> In-Reply-To: <016d01c6837e$5e948ef0$2800a8c0@DSX400> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Henry Sinnreich wrote: > The authors of this paper represent those who think there is a big > difference. Reasons include DNS caching conflicts with changing IP > addresses, security, etc. We drop the TTL to between 1 minute and 10 depending on how static the number block is, so caching issues can easily be dealt with in most instances (not including broken configuration on caching servers). > It would be interesting to learn why the 20 year old DNS 'as is' is > considered to be good enough for eternity and any successor technology does > not even merit a read, let alone reconsidering business evolution plans > based on 1986 technology. Reminds us of SS7 indeed... I think this is in the ball park of trying to replace email, and these technologies are ingrained into how people think operate rather then learning new technologies, not to mention they just work (if it ain't broke?)... This kind of reminds me of an article I was reading some time ago about what it takes for a new technology to actually make it (kind of like HDD/DVD/CD etc verses something like the zip disk/jazz drive)... The authors conclusion was it had to be a factor of 10 better then the old technology or people just didn't bother... -- Best regards, Duane _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 30 02:42:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkxvE-0001gE-1B; Tue, 30 May 2006 02:41:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkxvD-0001g9-6Z for speermint@ietf.org; Tue, 30 May 2006 02:41:43 -0400 Received: from mail.ficora.fi ([194.100.96.25] helo=portti1.ficora.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkxvA-0007ac-NY for speermint@ietf.org; Tue, 30 May 2006 02:41:43 -0400 Received: from POSTI.laru.local ([10.1.0.10]) by portti1.ficora.fi with InterScan Messaging Security Suite; Tue, 30 May 2006 09:52:59 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 30 May 2006 09:41:48 +0300 Message-ID: <07BC6C0D40216E44A34BE6701694FE86038B4626@POSTI.laru.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIAEEYoMAAEs7nCAACcsIAAAF4UfQAOV3R4AAcK35gAGOKOowAlM1CAABEhoIAAEbd+cA== From: "Nieminen Klaus" To: , "Francois D. Menard" , X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Richard, Francois and all, Francois, thanks for your proposal. If I understood the proposal by Francois correctly, you did not propose = to use OSP itself, but using the common data type definitions (format = and codes) defined in OSP. Therefore the problems Richard mentioned in = OSP should not apply to this case. I'm correct? What others think? Of course, providers can use this kind of mechanims for whatever they = like and I don't want to enter that discussion. I just want to point out = that we need something if we want to provide access to value added = services that are billed by the caller's operator. regards, - Klaus - -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us]=20 Sent: 30. toukokuuta 2006 1:04 To: 'Francois D. Menard'; Nieminen Klaus; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture You might think that and Alan Johnston did some work on this in SIPPING = but it seems no one cares...plus there are real issues of wether OSP can = scale to the number of transactions necessary to support this kind of = thing. Boys and Girls ... in case you had not heard transaction pricing for = voice is not all that popular among consumers these days. Transaction or distance based pricing for communications has not been = popular since the establishment of the penny post in the UK in the = 1800's.=20 http://www.dtc.umn.edu/~odlyzko/doc/history.communications0.pdf BTW Content is not king. http://firstmonday.org/issues/issue6_2/odlyzko/ ________________________________ From: Francois D. Menard [mailto:fmenard@xittelecom.com] Sent: Monday, May 29, 2006 9:46 AM To: 'Nieminen Klaus'; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Klaus, I've always thought we could put some Open Settlement Protocol XML data = in a SIP invite. F. -- Fran=E7ois D. M=E9nard Charg=E9 de projet Xit t=E9l=E9com inc. 1350 rue Royale #800 Trois-Rivi=E8res, QC, G9A 4J4 Canada fmenard@xittelecom.com Tel: (819) 374-2556 ext. 268 Fax: (819) 374-0395 Cell: (819) 692-1383 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 30 08:18:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl3A3-0000Nb-Bu; Tue, 30 May 2006 08:17:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl3A2-0000NW-RC for speermint@ietf.org; Tue, 30 May 2006 08:17:22 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl3A0-0003iC-FS for speermint@ietf.org; Tue, 30 May 2006 08:17:22 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Fl39r-0001hf-Bn; Tue, 30 May 2006 07:17:13 -0500 From: "Brian Rosen" To: "'Otmar Lendl'" , "'Reinaldo Penno'" Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 30 May 2006 08:17:09 -0400 Message-ID: <02e201c683e2$fcc9f7e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20060527095124.GJ1811@nic.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaBcygQnA3VO3/dRmScoe3KFSCrBQCboabQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: "'Khan, Sohel Q \[CTO\]'" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I believe this discussion has gone over the edge. The reason SPEERMINT exists is that CARRIERS want to peer. Email is an inappropriate metaphor for carrier peering. Email and normal SIP routing are approximately the same: Generally speaking, a domain accepts mail (calls) from any domain The mail (call) is marked by the sender with the domain of the recipient Mail (calls) is (are) exchanged over the open Internet You find the mail (sip) server by looking at the DNS entry for the domain I expect that some day, that IS the way we will do calls, but right now, carriers get paid to make calls work, and they want closed communities. At any point, a carrier or any other domain can just take a SIP URI and route it with normal RFC3261 routing to its destination URI. It's probably not the originating domain that cares, it's the terminating domain. As Richard points out rather frequently, SPEERMINT does not deal with E.164s, it deals with SIP URIs. They have the domain, but in SPEERMINT, we need something other than an SRV entry for the domain to be able to terminate it. Some day, we'll just do domain to domain calls, just like email, but that is not what SPEERMINT deals with. Brian -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at] Sent: Saturday, May 27, 2006 5:51 AM To: Reinaldo Penno Cc: Khan, Sohel Q [CTO]; speermint@ietf.org Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture On 2006/05/27 11:05, Reinaldo Penno wrote: > > I believe the crux of the problem was missed. > > The issue is not really the number of domains. We have today some > 400.000.000 million hosts on the Internet. BGP peers to do not exchange > 400.000.000 million routes, they exchange in the low hundreds of > thousands. > > And why is that? (I guess you know where I'm getting at). That's because > IP addresses lend themselves very well to hierarchical deployment, > compression through prefix/CIDR usage and the like. DNS names are > strings and hence difficult to come up with a similar scheme. That's because IP-addresses, are, eh, addresses. Routing information. They are (ignoring PI space / multihoming for the moment) provider- dependent and if you change provider you will also get new IP-addresses. Domains are NAMES. Not addresses. You usually own your domain and take it with you if you switch email provider or web-hoster. Domains itself contain NO ROUTING INFORMATION. Their hierarchical structure reflects the delegation chain but in no way L3 or application layer routing. I can host the webspace of my lendl.priv.at domain anywhere in the world, using any provider that sells webspace. The .at is no guarantee at all that the webserver is located in Austria. The DNS is used to map Domain NAMES to ADDRESSES which contain routing information. Any routing schema which operates on names is per definition not suitable for aggregation, because names are independent of network topology. > I believe that if domains need to be exchanged between peers: > > 1 - Just a limited set would be exchanged and a "default layer 5 route" > (equivalent to a traditional default route) would be used. This leads to suboptimal routing (e.g. consider nic.at calling vienna.ibm.com) and doesn't absolve the core networks from running a full routing table. > 2 - Compression schemes like *.company.com, regular expressions or the > like would need to be used. Having specific routes to AORs would be > hairy (maybe for the eventual roaming or visiting user). I wonder how > LNP is solved within wireless...A specific entry for each phone? That > would be crazy. I guess the Richards on this list can give you some details on that. But from all I know most LNP solutions require the exchange of at least one routing record per ported number. (Other solutions do onward routing, there the call traverses through the donor network. Yuck.) /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 30 08:26:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl3IQ-0003Yn-2c; Tue, 30 May 2006 08:26:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl3IP-0003Yi-7X for speermint@ietf.org; Tue, 30 May 2006 08:26:01 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl3IO-0004Je-4V for speermint@ietf.org; Tue, 30 May 2006 08:26:01 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Fl3IF-0002Gq-Ri; Tue, 30 May 2006 07:25:53 -0500 From: "Brian Rosen" To: "'Patrick Melampy'" , "'Michael Hammer \(mhammer\)'" , "'James McEachern'" , Subject: RE: [Speermint] Location Function in SPEERMINT Date: Tue, 30 May 2006 08:25:52 -0400 Message-ID: <02e301c683e4$32dacca0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200605262234192.SM03788@PMelampy> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAATumxgAG4BNwABEZoVAADQ2DIAAC1z/9AAGrFeAACZ2pfQABju7wACHfcEAAAbB9IAAK1HH6AAC9BtAAAGOAdAAAMvVgACTEanAAAMf18AAA1j4AAAEyrIAAAQ+GAAADlElAAAjeTVAAtGAzgA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0dcdaa57c570c86b2e4beb0ed476393e Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I think this is too much, or more appropriately, I think there is no point in standardizing a protocol mechanism to exchange permitted transaction rates or session/bandwidth quantity. It's not that I think we don't need this kind of limitations across a peering point, it's that I don't think there is a protocol involved, and I don't think standardizing the mechanism (which is just a provisioning process) gets us enough benefits to be worth while, at least now. I also think this is the kind of thing the terminating carrier has to enforce, and if it does, then there is not much value in having the originating carrier also do it; the terminating carrier can just say "enough". It's unlikely that the terminating carrier will trust the originating carrier to do the limits checking. The peering point could do that, but then you get to "which originating carrier gets in the gate when the line is full", and I don't think we want SPEERMINT to go there. So, I think the terminating carrier effectively sends back busy when it won't take any more traffic, and that is that. You might have contracts that specify the limits, but standardized mechanisms aren't really useful. Brian -----Original Message----- From: Patrick Melampy [mailto:PMelampy@acmepacket.com] Sent: Friday, May 26, 2006 10:34 PM To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'James McEachern'; speermint@ietf.org Subject: RE: [Speermint] Location Function in SPEERMINT I think SPEERMINT needs to help us locate and find adjacent proxies, and attributes about those proxies. This will enable peering to be more flexible and automatic -- as opposed to sharing lots of provisioning data and using static proxy definitions (which is the way carriers peer today). I also think that the attributes of proxies should include: Reachable domains Permitted transaction rates Permitted quantity of sessions/bandwidth This is my opinion of course -- based on extensive practice. Any subset of this type of information would be ok. Notice that I did not include any media anchor's, or other methods. I do believe that you are right, this should not be required. Also I believe that the originating network has total control over selection of the "crossing point". -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Friday, May 26, 2006 2:07 PM To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'James McEachern'; speermint@ietf.org Subject: RE: [Speermint] Location Function in SPEERMINT I think the question we want to ask in SPEERMINT is: do we care about any of this? It seems to me that the originating network, and the terminating network, will arrange their signaling through designated peering points. They can, if they want, designate media peering points by using SBCs or other mechanisms that effectively rewrite the SIP message bodies. I think that we can ignore that at the peering point, because when the call gets to the peering point, it's going to have the SDP offer in the INVITE; the media anchor has been decided. Now, in many cases, I expect that as part of its network, the originating network is going to do some kind of lookup (ENUM) that will tell it the destination network, and that could influence its choice of media anchor if it's doing things like that. The point is that I don't think SPEERMINT standardizes that behavior; it's a single element (some SIP proxy) making an internal decision, and routing the call within its network appropriately. Similarly, when the terminating network gets the call, it can make an internal decision to direct the media to some box in its network, which will show up in the answer SDP. Again, that is it's proxy making an internal routing decision. BETWEEN networks, which where we are working, I don't think we are doing any media routing beyond the normal SIP and IP packet stuff. Do I have that right? -----Original Message----- From: Patrick Melampy [mailto:PMelampy@acmepacket.com] Sent: Friday, May 26, 2006 12:23 PM To: 'Michael Hammer (mhammer)'; 'James McEachern'; speermint@ietf.org Subject: RE: [Speermint] Location Function in SPEERMINT One of the best arguments for the "composed" SBC is that if your going to need to locate the "closest media anchor", what better way than associating it with a proxy. If the requirement is to NOT manage the media, but rather let natural BGP4 style internetworking mechanisms route the media optimally, then there is no need to bother with identifying a location of a media anchor. So the real issue here in terms of requirements is: Will Carriers be able to use the autonomous system path (AS_PATH) for delivery and routing of media packets from all sources (customers and suppliers) to all sources (customers and suppliers.) Another way to say the same thing more simply, will carriers put all of the signaled media onto the public internet -- as it's the only internetwork available today. If the answer is NO, then there will need to be media anchors and NAT devices. The location of these devices will be important to the efficiency and manageability of the service offering. The signaling and routing components of the SIP network MUST be aware of the media path, as the signaling plane is establishing the media path. This awareness and state suggest that there needs to be a relationship between the signaling plane and media anchor that is understood and close. I'm going to suggest here that the location of the proxy (the nearest proxy) be a substitute for the nearest media anchor point. -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Friday, May 26, 2006 11:51 AM To: James McEachern; speermint@ietf.org Subject: RE: [Speermint] Location Function in SPEERMINT I think I have lost track of what "it" is. I don't think "it" is the ability to identify a proxy that a peer should use based on location. "It" may be the ability to identify a proxy that a peer should use based on the peer identity or affiliation (federation). "Location" has geographic baggage when perhaps selective "discovery" is really what is meant. Please correct me as I may have gotten disoriented with the different mail threads. Mike > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com] > Sent: Friday, May 26, 2006 11:16 AM > To: Michael Hammer (mhammer); speermint@ietf.org > Subject: RE: [Speermint] Location Function in SPEERMINT > > So are you saying that it should be a requirement? > > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, May 26, 2006 10:52 AM > To: McEachern, James [CAR:5N00:EXCH]; Reinaldo Penno; Stastny > Richard; timothy.dwight@verizon.com; > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; > Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > Subject: RE: [Speermint] Location Function in SPEERMINT > > Distance is dead IF the proxy does not have strong ties to a > media anchor point. If there is such a media anchor point, > then choosing ones that are close to calling and called > parties will aid in finding shortest routes between parties. > > However, I am not advocating for or against such media > anchors, just simply recognizing that they may exist > depending on a domain's architecture. > > There may be other reasons that peers are directed to one > proxy over another. It is useful for the domain to designate > which proxies peers should use. > > Mike > > > > -----Original Message----- > > From: James McEachern [mailto:jmce@nortel.com] > > Sent: Friday, May 26, 2006 10:44 AM > > To: Reinaldo Penno; Stastny Richard; > > timothy.dwight@verizon.com; Michael Hammer (mhammer); > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > > Sohel Q [CTO]; David Meyer; speermint@ietf.org > > Subject: RE: [Speermint] Location Function in SPEERMINT > > > > >This tells you the SIP proxy to be contacted. It does not > > tell you if > > >this the closest Sip Proxy handling @example.com users. It > also does > > >not tell you if it is the closest proxy to the callee. > > > > Is the ability to "identify the closest proxy" a requirement for > > Speermint? Many people have pointed out that distance is > dead, or at > > least should be, so it isn't clear to me that we really care. The > > Requirements and Terminology draft doesn't explicitly say, but my > > reading of section 5.2 implies this is not a requirement. > > > > That having been said, I don't necessarily have strong views either > > way. I'd just like to be clear on whether or not it is a > requirement. > > > > Jim > > > > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Thursday, May 25, 2006 5:00 PM > > To: Stastny Richard; timothy.dwight@verizon.com; Michael Hammer > > (mhammer); timothy.dwight@verizon.com; Brian Rosen; Francois D. > > Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > > Subject: RE: [Speermint] Location Function in SPEERMINT > > > > I believe it is enough. You could refine it but I might sure of the > > benefits. Maybe this problem was already solved somewhere > and I'm not > > aware. > > > > For example, The UAs would care. > > > > >From RFC3263 > > > > ;; Priority Weight Port Target > > IN SRV 0 1 5060 server1.example.com > > IN SRV 0 2 5060 server2.example.com > > > > This tells you the SIP proxy to be contacted. It does not > tell you if > > this the closest Sip Proxy handling @example.com users. It > also does > > not tell you if it is the closest proxy to the callee. > > > > In the case of a carriers providing VoIP service to a user, if this > > provider A peers with provider B in two different > locations, which one > > to choose to send to forward the call? > > > > Regards, > > > > Reinaldo > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, May 25, 2006 1:52 PM > > > To: Reinaldo Penno; timothy.dwight@verizon.com; Michael Hammer > > (mhammer); > > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > > Sohel Q > > > [CTO]; David Meyer; speermint@ietf.org > > > Subject: Re: [Speermint] Location Function in SPEERMINT > > > > > > Reinaldo said: > > > >That's maybe one of the most important issues. This could be > > complicated > > > >by the geographically dispersed networks with several > entry points. > > > >Although this might be an interesting problem it might be > > a rathole. > > > > > > So you say RFC 3263 is not enough, something is missing? > > > e.g. the geographic location of originating and terminating > > --- what? > > > > > > -SIP proxy? who cares > > > -SBC? > > > -UA? > > > > > > So we are again dealing with SBCs, in this case the > geo-location of > > these > > > -- rats, holes ;-) > > > > > > Richard > > > > > > > > > ________________________________ > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Gesendet: Do 25.05.2006 22:37 > > > An: Stastny Richard; timothy.dwight@verizon.com; Michael Hammer > > (mhammer); > > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > > Sohel Q > > > [CTO]; David Meyer; speermint@ietf.org > > > Betreff: RE: [Speermint] Location Function in SPEERMINT > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, May 25, 2006 1:26 PM > > > > To: timothy.dwight@verizon.com; Michael Hammer (mhammer); > > > > timothy.dwight@verizon.com; Brian Rosen; Francois D. > Menard; Khan, > > > Sohel Q > > > > [CTO]; David Meyer; speermint@ietf.org > > > > Subject: [Speermint] Location Function in SPEERMINT > > > > > > > > Hi all, > > > > > > > > sorry, but I am only able to reply with a short > > statement, because I > > > am > > > > on vacation and have only limited time and bandwitdh (GPRS) > > > > > > > > First, I consider this discussion regarding Infrastructure ENUM, > > LERG > > > and > > > > LNP > > > > important, but in the wrong WG. It should be discussed > in ENUM. WG > > and > > > > not in SPEERMINT > > > > > > > > SPEERMINT is only dealing with Call Routing Data (CRD), which is > > > defined > > > > as the OUTPUT of ENUM or some other means. > > > > > > > > This implies, that the location function (LF) defined in the > > > > achitecture draft happens AFTER an ENUM query and > > therefore cannot > > > > be the part of the LF. > > > > > > > > The LF can only involve the location of the destination > "network" > > > > as defined in SPEERMINT by the use of CRD (which is > > basically a SIP > > > > URI because we are currently talking only SIP in SPEERMINT) > > > > > > > > Of course SPEERMINT needs to define what it considers > > CRD, and AoR > > > > or the ingress point of a network. > > > > > > > > BUT then SPEERMINT needs also to define how the ingress > > point of a > > > > "network" is LOCATED given a SIP AoR. > > > [[Reinaldo]] > > > > > > That's maybe one of the most important issues. This could be > > complicated > > > by the geographically dispersed networks with several > entry points. > > > Although this might be an interesting problem it might be > a rathole. > > > > > > > > > > > > > > Richard > > > > > > > > > > > > ________________________________ > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > Gesendet: Do 25.05.2006 20:17 > > > > An: 'Michael Hammer (mhammer)'; > > timothy.dwight@verizon.com; Stastny > > > > Richard; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, > > Sohel Q [CTO]'; > > > > 'David Meyer'; speermint@ietf.org > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering > Architecture - LF - > > OF > > > - SF > > > > > > > > > > > > > > > > Michael Hammer said: > > > > > > > > > Tim, > > > > > > > > > > The LERG and LNP databases are intrinsically tied to > > the operation > > > of > > > > the > > > > TDM > > > > > infrastructure. Any design that perpatuates these > systems when > > > their > > > > reason > > > > > for being (TDM) goes away is a faulty design. > > > > > > > > OK with me. I only meant to point out that right now I > > have these > > > > capabilities, so recreating them isn't a high priority. > > > > > > > > > > > > > > > > > > DNS and ENUM provides the equivalent information and > > mechanisms to > > > do > > > > what > > > > is > > > > > needed in the IP domain. As such, a design that makes > > dependencies > > > on > > > > legacy > > > > > systems is deficient. I wouldn't support such a kludge. > > > > > > > > Fine. > > > > > > > > I'm a big fan of IP-domain solutions. Specifically > Infrastructure > > > ENUM > > > > looks really handy; my point before was that it's > moreso when used > > in > > > what > > > > Richard called "option 1". The alternative ("option 2") only > > > replicates > > > > the > > > > "kludge" to which I already have access. > > > > > > > > And to be fair to Richard, he did point out (subtly) that > > the latter > > > claim > > > > is a bit myopic. There are existing means by which > VSPs can gain > > > access > > > > to > > > > number portability information relative to national > destinations. > > > They > > > > don't have such access, at least not easily and not > > universally, to > > > number > > > > portability information relative to international > > destinations. If > > > that > > > > could be provided by Infrastructure ENUM (either "option 1" or > > "option > > > 2") > > > > it would be useful and would not simply replicate existing > > > capabilities. > > > > > > > > Bottom line, both options defined by Richard, would add value. > > Option > > > 1 > > > > adds more value but is specific to destinations > > identified by E.164 > > > > numbers or URIs with imbedded E.164 numbers. Which is > > the problem > > > > closest > > to > > > > hand. > > > > > > > > > > > > > > > > > > That said, if there are backward compatibilities during the > > > transition, > > > > where > > > > > some information just happens to be known by external systems, > > such > > > as > > > > you > > > > suggest > > > > > below, I don't see that as a problem. I am just wary > > of ending up > > > with > > > > two > > > > > systems in the end when one would do. > > > > > > > > Isn't it inevitable that for some time, both will > exist? Just as > > the > > > GSTN > > > > and VoIP will coexist for some time, so will their supporting > > > > infrastructure. > > > > > > > > Don't get me wrong. I'm not saying "because I have an > SS7 -based > > > solution > > > > to LNP I don't need an IP -based solution". All I'm > > saying is that > > > when > > > > given the option of using Infrastructure ENUM to > recreate (and in > > the > > > case > > > > of international destinations, extend) the capability I already > > have, > > > and > > > > using it to do that and more, I'm inclined to prefer the latter. > > > > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > > Sent: Wednesday, May 24, 2006 6:19 PM > > > > > To: 'Stastny Richard'; timothy.dwight@verizon.com; > > > > > timothy.dwight@verizon.com; Michael Hammer (mhammer); 'Brian > > Rosen'; > > > > > 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; > > > > > speermint@ietf.org > > > > > Subject: RE: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > OF > > > > > - SF > > > > > > > > > > Richard, > > > > > > > > > > Yes I know I was mixing data and mechanism-to-access-data. > > > > > Still I believe the major point to be correct. In > many parts of > > the > > > > > world there are already mechanisms (associated with > Local Number > > > > > Portability) to determine ownership of an E.164 number, > > hence use > > of > > > > > ENUM for this purpose alone, will be unnecessary. > > > > > > > > > > To be clear, I believe that providing access via > Infrastructure > > ENUM > > > > > to LNP information may be very helpful; but only if > > Infrastructure > > > > > ENUM provides more than just this. > > > > > If an Infrastructure ENUM query can combine (a) > > determination of > > > the > > > > > entity providing service to the destination, (b) > > determination of > > > the > > > > > corresponding LRN, if one exists, and (c) mapping of > > the routable > > > > > number (either the number originally indicated, or > the LRN) to a > > > Layer > > > > > 5 "point of ingress" specified by the entity providing > > service to > > > the > > > > > destination; then Infrastructure ENUM is quite a handy > > mechanism. > > > If > > > > > all it does is (a) then I don't need it. > > > > > > > > > > But in the end this is neither here nor there. I am > > not wedded to > > > any > > > > > specific technology, I just need workable solutions to real > > business > > > > > problems. > > > > > > > > > > Tim > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Wednesday, May 24, 2006 4:38 PM > > > > > To: timothy.dwight@verizon.com; timothy.dwight@verizon.com; > > Michael > > > > > Hammer (mhammer); Brian Rosen; Francois D. Menard; > > Khan, Sohel Q > > > > > [CTO]; David Meyer; speermint@ietf.org > > > > > Subject: Re: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > OF > > > > > - SF > > > > > > > > > > Tim, > > > > > > > > > > thanx for your reply, you are raising some important issues. > > > > > Since it is already midnight here, I will reply to it > in detail > > > > > tomorrow > > > > > > > > > > I am also working on a more detailed analysis and a > draft which > > will > > > > > require even some more time. > > > > > > > > > > Just a quick one: > > > > > > > > > > >In some parts of the world the function provided by "option > > > > > 2" usage of > > > > > >Infrastructure ENUM could be achieved in other ways (e.g., > > > > > the LERG and > > > > > >NPDB in North America) so in those cases Infrastructure ENUM > > > > > might be a > > > > > >superfluous concept; but if that's the right technical > > > > > answer so be it. > > > > > > > > > > Yes and no ;-) > > > > > You are mixing up here the Registry and the ENUM DNS. > > > > > The Registry is the LERG and NPDB (or is derived > from), the ENUM > > DNS > > > > > is the equivalent on IP of the SCP in the PSTN where > > the date is > > > > > downloaded to. > > > > > > > > > > Richard > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > > Gesendet: Mi 24.05.2006 23:00 > > > > > An: Stastny Richard; timothy.dwight@verizon.com; > > 'Michael Hammer > > > > > (mhammer)'; 'Brian Rosen'; 'Francois D. Menard'; > 'Khan, Sohel Q > > > > > [CTO]'; 'David Meyer'; speermint@ietf.org > > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > OF > > > > > - SF > > > > > > > > > > > > > > > > > > > > Richard, > > > > > > > > > > Thank you for the clarification. I understand the > > distinction you > > > are > > > > > making. > > > > > > > > > > My objective is to be able to translate a destination > identifier > > > > > (E.164 number of alphanumeric AoR) into the address of > > a Layer 5 > > > > > entity designated by the organization providing service to the > > > called > > > > > party. With infrastructure/carrier ENUM I could do this (as > > > described > > > > > in your Option 1), but because ENUM is specific to > E.164 numbers > > it > > > > > would only work for E.164 -formatted destination identifiers. > > > > > > > > > > In pictures, your Option 2 seems to me to imply the following: > > > > > > > > > > +----------------+ +----------+ > > > > > E.164 | infrastructure | serving | identify > > > > > | network > > > > > ingress > > > > > destination -->| ENUM |---> carrier --->| ingress > > > > > |---> point > > > > > specified > > > > > identifier | (option 2) | identity | point | > > > by > > > > > serving carrier > > > > > +----------------+ ^ +----------+ > > > > > | > > > > > +----------------+ | > > > > > non-E.164 | map domain in | | > > > > > Destination -->| URI to carrier |--------+ > > > > > Identifier | identity | > > > > > +----------------+ > > > > > > > > > > In some parts of the world the function provided by "option 2" > > usage > > > > > of Infrastructure ENUM could be achieved in other ways > > (e.g., the > > > LERG > > > > > and NPDB in North America) so in those cases > Infrastructure ENUM > > > might > > > > > be a superfluous concept; but if that's the right > > technical answer > > > so > > > > > be it. > > > > > > > > > > The "identify ingress point" function would need to be > > defined. I > > > > > would like it to consider the specified destination > (in addition > > to > > > > > the carrier providing service to that destination); > and I would > > like > > > > > the procedures to be such that the serving carrier > > controls (in a > > > > > reasonably dynamic > > > > > way) the point at which traffic destined to a particular > > > destination, > > > > > enters his network. If those requirements can be met, I think > > this > > > > > approach is workable. > > > > > > > > > > Its biggest drawback is that it precludes a solution > ("option 1" > > > usage > > > > > of Infrastructure ENUM) that is sufficient for the majority of > > > today's > > > > > needs. > > > > > It optimizes for a problem that will exist in the > future at the > > > > > expense of solving problems that exist today. I realize that > > > solving > > > > > today's problems may not be SPEERMINT's focus, or > > (arguably) even > > > > > within its charter, but I would hate to see > > recommendations from > > > > > SPEERMINT preclude or significantly delay solving them. > > > > > > > > > > Suppose we did something like this: > > > > > > > > > > +----------+ [pseudo +----------------+ > > > > > non-E.164 | identify | or real] | infrastructure > > > > > | network > > > > > ingress > > > > > destination -->| "pseudo" |---> E.164 --->| ENUM > > > > > |---> point > > > > > specified > > > > > identifier | E.164 | number | (option 1) | > > > by > > > > > serving carrier > > > > > +----------+ +----------------+ > > > > > > > > > > We could let the ENUM working group define > > Infrastructure ENUM as > > > > > described in your Option 1 (which is as you know already > > > commercially > > > > > available from a few sources) and SPEERMINT could define the > > > "identify > > > > > pseudo E.164" function that in my diagram feeds into > it. This > > > > > function might be as simple as mapping the domain part > > of the URI > > to > > > > > an E.164 number uniquely associated with the network providing > > > service > > > > > to the specified destination. Unless this is a lot > > harder than it > > > > > seems, this shouldn't keep us busy too long :-) > > > > > > > > > > > > > > > Tim > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Wednesday, May 24, 2006 11:16 AM > > > > > To: timothy.dwight@verizon.com; Michael Hammer > (mhammer); Brian > > > > > Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer; > > > > > speermint@ietf.org > > > > > Subject: Re: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > > > OF - SF > > > > > > > > > > Tim, > > > > > > > > > > >> ... the basic idea of Infrastructure ENUM (which > will be used > > for > > > > > >> service providers is to provide a domain name in a > > SIP URI = a > > > > > >> service provider ID > > > > > >(SPID) > > > > > > > > > > >At the risk of asking an off-topic question (realizing that > > > > > ENUM is not > > > > > >within scope for SPEERMINT), can I ask where the idea that > > > > > >Infrastructure ENUM queries return SPIDs, comes from? It is > > > > > my intent > > > > > >to provide a point of interconnection to be used by the > > requesting > > > > > >entity to hand to me a call to the specified number. I do > > > > > not intend > > > > > >that the only meaningful part of the URI returned from the > > > > > ENUM query, > > > > > >be > > > > > the domain name. > > > > > > > > > > thank you for raising this important point. I tried to > > raise this > > > > > some time ago, but got no clear answer > > > > > > > > > > Currently there exist two lines of thought about the usage of > > > > > Infrastructure (and also Carrier ENUM in private trees) > > > > > > > > > > 1. Put in ENUM the ingress point(s) e.g. > > > > > sip:+43xxxx@sbc4711.provider.net 2. > > > > > Put in ENUM the AoR only: e.g. sip:+43xxx@provider.net > > > > > (provider.net is what I meant with SPID) > > > > > > > > > > Most currently prefer option 1, especially in private > > ENUM trees. > > > > > > > > > > IMHO this is the wrong approach: > > > > > > > > > > There should be a clear separation (and it is in the charter) > > > > > between ENUM and SPEERMINT SPEERMINT peering MUST be > > able to work > > > > > standalone and without ENUM. > > > > > > > > > > Option 1 assumes also that the user is entering ALWAYS an > > > > > E.164 number as identifier. > > > > > > > > > > But what if he is entering an AoR? > > > > > > > > > > SPEEMINT peering MUST be able to resolve this too so > > you need to > > > > > find the ingress point independant of ENUM e.g. via RFC3263. > > > > > > > > > > If this MUST be possible, why not enter in (any) ENUM > just the > > > > > AoR, if you must be able to resolve the AoR anyway? > > > > > > > > > > Otherwise you need to manage two mappings separate 1. the > > > > > E.164 to ingress point 2. the AoR mapping to ingress point > > > > > > > > > > this is not a good idea > > > > > > > > > > This is the reason why I would prefer to enter in ENUM > > AoRs only > > > > > the user part in ENUM is always the E.164 number (for privacy > > > > > reasons) the domain part is the SPID, which is mapped > later to > > > > > find the ingress point > > > > > > > > > > the calling user may then also use an alis AoR such as > > > > > sip:name@provider.net > > > > > > > > > > regards > > > > > > > > > > Richard > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > > Gesendet: Mi 24.05.2006 16:46 > > > > > An: Stastny Richard; 'Michael Hammer (mhammer)'; > 'Brian Rosen'; > > > > > 'Francois D. > > > > > Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; > > speermint@ietf.org > > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering > > Architecture - LF - > > > > > OF - SF > > > > > > > > > > > > > > > > > > > > Stastny, Richard said: > > > > > > > > > > > ... the basic idea of Infrastructure ENUM (which > will be used > > for > > > > > > service providers is to provide a domain name in a SIP URI > > > > > = a service > > > > > > provider ID > > > > > (SPID) > > > > > > > > > > At the risk of asking an off-topic question (realizing > > that ENUM > > > > > is not within scope for SPEERMINT), can I ask where the > > idea that > > > > > Infrastructure ENUM queries return SPIDs, comes from? > It is my > > > > > intent to provide a point of interconnection to be > used by the > > > > > requesting entity to hand to me a call to the specified > > number. I > > > > > do not intend that the only meaningful part of the > URI returned > > > > > from the ENUM query, be the domain name. > > > > > > > > > > tim > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 30 09:40:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl4SX-0003K5-69; Tue, 30 May 2006 09:40:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl4SV-0003K0-SM for speermint@ietf.org; Tue, 30 May 2006 09:40:31 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fl4SV-0003pC-1y for speermint@ietf.org; Tue, 30 May 2006 09:40:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: WG: [Speermint] LNP today and routing by domain tomorrow Date: Tue, 30 May 2006 15:44:03 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A8D@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] LNP today and routing by domain tomorrow Thread-Index: AcaD7anPP3JhR7xaTkOd9mRCDsdMcwAARDLFAAAYlj4= From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org =20 ________________________________ Von: Stastny Richard Gesendet: Di 30.05.2006 15:41 An: Otmar Lendl; Pfautz, Penn L, GBLAM Betreff: Re: [Speermint] LNP today and routing by domain tomorrow Penn, =20 I fully agree with Otmar. I just want to add that particularly every enterprise wants to have their domain name as SIP URI =20 So this problem must be addressed =20 Richard ________________________________ Von: Otmar Lendl [mailto:lendl@nic.at] Gesendet: Di 30.05.2006 15:29 An: Pfautz, Penn L, GBLAM Cc: Stastny Richard Betreff: Re: [Speermint] LNP today and routing by domain tomorrow Penn, if ATT were to market their VoIP service in Austria and I became a customer, I could add _sip._udp.lendl.priv.at. IN SRV 10 10 5060 vienna.sip.att.net. to my private domain and thus publish the fact that all callers should contact ATT's SIP proxy in Vienna if they have calls for . Any Speermint peering protocol could operate on "vienna.sip.att.net" just as easily as on "lendl.priv.at". This is quite the same as lendl.priv.at. IN MX 10 smtp-in.att.net. (The NAPTRs in RFC3263 just provide one more level of abstraction) /ol On 2006/05/30 14:05, "Pfautz, Penn L, GBLAM" wrote: > Maybe, but the point is that it's point in this case to a service > provider owned element instead of a domain name owner (user) element. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, May 30, 2006 8:57 AM > To: Pfautz, Penn L, GBLAM; Otmar Lendl > Subject: Re: [Speermint] LNP today and routing by domain tomorrow > > >some VoIP equivalent of a MX record. >=20 > SRV? >=20 > Richard > > ________________________________ > > Von: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] > Gesendet: Di 30.05.2006 14:47 > An: Otmar Lendl > Cc: Reinaldo Penno; Stastny Richard > Betreff: RE: [Speermint] LNP today and routing by domain tomorrow > > > > Otmar: > Where I fall off the train is (2). This assumes that everyone gets and > uses SIP URIs that are not service provider-dependent and service > providers want to peer using these. > I really don't think this is going to happen but if it did the obvious > solution is some sort of parallel to I-ENUM that maps customer domain > names to serving carrier. You might even have a some other DNS > infrastructure that maps user domain name to carrier, some VoIP > equivalent of a MX record. This is the right way to do domain name > portability. > These would avoid the need to bounce around large number of domain > names, just as ENUM avoid the need to exchange lots of E.164 info as = in > TRIP. In either case, I think this is out of scope for Speermint, just > as ENUM is, and should be done elsewhere. > > Penn > > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Tuesday, May 30, 2006 5:06 AM > To: Pfautz, Penn L, GBLAM > Cc: Reinaldo Penno; Stastny Richard > Subject: Re: [Speermint] LNP today and routing by domain tomorrow > > On 2006/05/29 23:05, "Pfautz, Penn L, GBLAM" wrote: > > > > 2. In terms of exchanging domain info. I'm not sure I follow the > > scenario. I don't expect so many domains to be relevant if peering = is > > service provider to service provider. > > Well, that depends. > > Usually you have > > Public Name ---mapping protocol---> Routing address > Routing address ---routing protocol---> Nexthop decisions. > > In the case of the US PSTN, the public name is the E.164 number > and the NPAC is the mapping to the routing address (whatever that > is, I guess carrierID/SwitchID/LineID or something like that). > > Based on that, the call is routed within the network. > > The routing address is never seen by the customer. He can't dial it > and he won't print it on business cards. > > --- > > Email is similar: > Public name is the email address, mapping is done by the DNS. > Routing address is the IP address of the mail-server, and > via BGP a provider knows how to contact that mail-server. > > You could reach me if you send mail to lendl@[193.154.150.108], but > that is guaranteed to change once I move my box to a different ISP. > > --- > > So what do we have in terms of I-ENUM/Speermint? I see two different > scenarios: > > 1) The user only uses E.164 addresses. He never knows or dials SIP = URIs. > > In that case we have: > > Public Name =3D E.164 number > Mapping protocol =3D I-ENUM > Routing address =3D SIP URI with the provider domain (maybe even > including > a specific SIP proxy within his network) > Routing protocol =3D either plain RFC3263 or whatever speermint = comes > up with > > In this case you can deploy a routing protocol based on domains. > Number portability is only done at the I-ENUM step. > > If a customer switches provider, he'll get a new SIP URI. He won't > notice as he didn't knew his old one either. > > 2) The user knows his SIP URI, will print it on business cards and = might > dial SIP URIs. > > It is no longer acceptable that the user has to change his URI when > he chooses to switch providers, or if the provider moves him to a > different SIP proxy within his network. > > Assuming we don't want to go into onward-routing (brrr!) or > routing protocols involving the username-part of the SIP URI = (yuck!), > we have no choice but to allow the customer to use his own domain > for his SIP URI. > > Now we have two possible dial-strings: > > a) Public Name =3D E.164 number > AND > b) Public Name =3D SIP URI with the customer's domain > > For a) we could use the same options as in 1). > =20 > Or: ENUM can map case a) to case b). > > For b) we can do > > Public Name =3D SIP URI with the customer's domain > Mapping protocol =3D DNS according to RFC3263 > Routing address =3D IP address of SIP proxy > Routing protocol =3D BGP > > (This is the end-to-end SIP view) > > Or: > > Public Name =3D SIP URI with the customer's domain > Mapping protocol =3D DNS according to = draft-lendl-domain-policy-ddds-00 > Routing address =3D Federation ID + SIP domain > Routing protocol =3D Federation-specific (for which speermint can > provide an example) > > ------- > > As I read the Speermint charter, we need to provide a solution for 2) = as > well. > > > > If everybody really doesn't = use > > E.164 but chooses to reinvent the wheel again by having their own > > domain, then we'll need DNS RRs that specify a VoIP service provider > > similar to what infrastructure ENUM will do for E.164. > > Am I missing something? > > I consider "using customer-owned domains for public user IDs" not a > new idea. It's been successfully used in email, web and in most other > Internet communication protocols. Have a look at the IMS specs in = terms > of Private User Identity vs. Public User Identity. > > That concept has proven to be very useful. > > Well, RFC3263 already contains a (actually, three) mapping steps. > Eg. let's reword an example from 3263 a bit: > > > As an example, consider a client that wishes to resolve > sip:user@customer.us. The client performs a NAPTR query for that > domain, and the following NAPTR records are returned: > > ; order pref flags service regexp replacement > IN NAPTR 50 50 "s" "SIPS+D2T" "" = _sips._tcp.example.com. > IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.com > IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.com. > > This indicates that the server supports TLS over TCP, TCP, and UDP, > in that order of preference. Since the client supports TCP and = UDP, > TCP will be used, targeted to a host determined by an SRV lookup of > _sip._tcp.example.com. That lookup would return: > > ;; Priority Weight Port Target > IN SRV 0 1 5060 server1.bigtelco.net > IN SRV 0 2 5060 server2.bigtelco.net > > > So there are already DNS RRs which can provide this mapping from > a customer domain to the carrier's domain. This can be done > at the NAPTR step, the SRV step or even at the A record step. > > All that draft-lendl-domain-policy-ddds-00 does is offer some more > options during the NAPTR step. The DNS query is exactly the same: > "please give me all NAPTR records for this destination domain". > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Summary: We really need to decide whether we consider the SIP URIs > with which deal within Speermint as private, network-internal > addresses, or whether they are customer-visible and thus public > identifiers. > > A number of design choices depend on that decision. > > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 30 11:22:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl63D-0005rU-JK; Tue, 30 May 2006 11:22:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl63C-0005rP-P2 for speermint@ietf.org; Tue, 30 May 2006 11:22:30 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl637-0005fr-Js for speermint@ietf.org; Tue, 30 May 2006 11:22:30 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Tue, 30 May 2006 11:22:56 -0400 id 01588107.447C6350.00007CFA Message-ID: <447C632A.4030500@hxr.us> Date: Tue, 30 May 2006 11:22:18 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture References: <32755D354E6B65498C3BD9FD496C7D462C4A7F@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4A7F@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Stastny Richard wrote: > > IMHO SPEERMINT does not deal with E.164 numbers at all in routing, it is out of scope Would the "private" ENUM tree run by a peering point and specifying its location (i.e. DNS suffix) be in scope? -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 30 11:29:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl6AE-0000tV-7o; Tue, 30 May 2006 11:29:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl6AC-0000tQ-Ch for speermint@ietf.org; Tue, 30 May 2006 11:29:44 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fl6AB-00062T-2w for speermint@ietf.org; Tue, 30 May 2006 11:29:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 30 May 2006 17:31:50 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A92@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaD/W9wzhdOOV+xRZWp3yzFsp5u8wAALw+x From: "Stastny Richard" To: "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Andy wrote >Stastny Richard wrote: >> >> IMHO SPEERMINT does not deal with E.164 numbers at all in routing, it = is out of scope >Would the "private" ENUM tree run by a peering point and specifying its >location (i.e. DNS suffix) be in scope? IMHO yes, because any ENUM is dealing with E.164 numbers -sta=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 30 12:54:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl7U8-0002Lz-EJ; Tue, 30 May 2006 12:54:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl7U7-0002Lf-SX for speermint@ietf.org; Tue, 30 May 2006 12:54:23 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl7U6-0006JG-Kg for speermint@ietf.org; Tue, 30 May 2006 12:54:23 -0400 Received: from ([10.52.116.31]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.20539225; Tue, 30 May 2006 12:53:54 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 May 2006 12:53:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 30 May 2006 12:53:53 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96581D9B@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaBIeJdKNbbz72dRV+rDUhKcqICvwC55Cpg From: "Livingood, Jason" To: "Otmar Lendl" X-OriginalArrivalTime: 30 May 2006 16:53:54.0157 (UTC) FILETIME=[A271B1D0:01C68409] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > I still have a serious problem regarding how to bootstrap=20 > such a system as >=20 > * Carriers seem to hate to expose their SIP ingress elements=20 > to the open > Internet. They firewall, use private address spaces (e.g. GRX) or > otherwise block incoming SIP calls before they reach the SIP stack. But that shouldn't be a design constraint just yet. These same carriers expose their SMTP gateways on the open Internet. We need to find a middle ground between SMTP (say, by reducing abuse for a start) and the current model of firewalled SIP ingress points. Jason =20 > * we want to avoid a mandatory bilateral configuration of peerings. > =20 > Could you sketch how a dynamic peering discovery could work=20 > with a SIP subscription model? >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 30 12:58:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl7Xt-0002wj-KK; Tue, 30 May 2006 12:58:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl7Xs-0002we-M8 for speermint@ietf.org; Tue, 30 May 2006 12:58:16 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl7Xq-0006pT-OG for speermint@ietf.org; Tue, 30 May 2006 12:58:16 -0400 Received: from ([10.20.62.12]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.20539540; Tue, 30 May 2006 12:57:29 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCRLY02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 May 2006 12:57:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] RE: Closing Issue SIP Interoperablity (Section 4.3:draft-khan-ip-serv-arch-02) Date: Tue, 30 May 2006 12:57:48 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96581D9C@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Closing Issue SIP Interoperablity (Section 4.3:draft-khan-ip-serv-arch-02) Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAANiSfAAGpkGwABFyNDAABcvUoAAA7iiQAELeetAAAMAqIAAO6n1wACEPZuAAApzSgAAA8TLwAMIAPjA= From: "Livingood, Jason" To: "Khan, Sohel Q [CTO]" X-OriginalArrivalTime: 30 May 2006 16:57:48.0826 (UTC) FILETIME=[2E5157A0:01C6840A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Jean-Francois Mule , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org We are beginning to track this. As Dave updated the terminology draft and parked the requirements from the earlier versions, we're now working on a -00 of requirements. We have asked Jean-Francois Mule to be the editor of this document, and he's kindly agreed to lend the WG his expert help. If any of you have your own list of requirements, send them to Jean-Francois or hold onto them for comment after -00 comes out before Montreal. Regards Jason > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com]=20 > Sent: Friday, May 26, 2006 4:26 PM > To: Brian Rosen; Francois D. Menard; James McEachern; Stastny=20 > Richard; speermint@ietf.org; Michael Hammer (mhammer); David Meyer > Subject: [Speermint] RE: Closing Issue SIP Interoperablity=20 > (Section 4.3:draft-khan-ip-serv-arch-02) >=20 > Okay, we will not close this issue! > Some RFCs **must** be supported: these are the minimum set of RFCs. > Which RFCs are those? {3261, ...} > Some RFCs **should** be supported: these RFCs needs to be=20 > supported in general. > Which RFCs are those? >=20 >=20 > =20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, May 26, 2006 3:02 PM > To: Khan, Sohel Q [CTO]; 'Francois D. Menard'; 'James=20 > McEachern'; 'Stastny Richard'; speermint@ietf.org; 'Michael=20 > Hammer (mhammer)'; 'David Meyer' > Subject: RE: Closing Issue SIP Interoperablity (Section 4.3: > draft-khan-ip-serv-arch-02) >=20 > Why do you think you can get away with ignoring such things=20 > as, say "UPDATE"? Do you really think we can say=20 > "implementations should not assume UPDATE will work across=20 > the peering point"? >=20 > I think closing off this issue will require an extended discussion. >=20 > Brian >=20 > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: Friday, May 26, 2006 2:49 PM > To: Francois D. Menard; Brian Rosen; James McEachern; Stastny=20 > Richard; speermint@ietf.org; Michael Hammer (mhammer); David Meyer > Subject: Closing Issue SIP Interoperablity (Section 4.3: > draft-khan-ip-serv-arch-02) >=20 > =20 > Thank you for all suggestions and comments on the SIP=20 > Interoperability (Section 4.3: draft-khan-ip-serv-arch-02)=20 > paragraph in Speermint Peering Architecture draft. Based on=20 > the discussion, I would propose to close the issue by=20 > replacing the current paragraph, "SIP Interoperability:TBD" > with the following paragraph. >=20 > "SIP Interoperability: SPEERMINT Signaling Function (SF) in=20 > general should support all SIP RFCs identified in the SIP=20 > hitchhiker's guide. > The SF must minimally support RFC 3261, 3263, 3325, and 3326.=20 >=20 > A SPEERMINT SIP Profile document would recommend a rationale=20 > set of SIP profiles to perform smooth interoperability. The=20 > document will also contain information on the population of=20 > the header fields, particularly in context with phone numbers=20 > (e.164 and non-E.164). >=20 > A SPEERMINT SIP Flow Document would recommend call flows and=20 > establishment of two-way TLS connections." >=20 > Please do not criticize! Instead, suggest another paragraph=20 > or a better version of this paragraph. >=20 > Sohel Khan, Ph.D. > Technology Strategist > Sprint-Nextel > 913-794-1470 (office) > 913-486-3145 (cell) >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 30 13:12:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl7km-0007Mu-T1; Tue, 30 May 2006 13:11:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl7kl-0007Mp-RQ for speermint@ietf.org; Tue, 30 May 2006 13:11:35 -0400 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl7kk-0007Rl-3h for speermint@ietf.org; Tue, 30 May 2006 13:11:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 30 May 2006 13:11:05 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96581D9E@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaBe8O8SFWQQ/DZQo+7tlNbLyML9QCj3I/w From: "Livingood, Jason" To: "Otmar Lendl" X-OriginalArrivalTime: 30 May 2006 17:11:06.0111 (UTC) FILETIME=[098960F0:01C6840C] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > Let's do a quick estimate on the number of domains involved: >=20 > Right now, operators usually give customers URIs of the form=20 > @. As long as this is the state of=20 > affairs, we're fine as the number of providers is quite=20 > finite (a few thousands, perhaps). >=20 > This is like the state of affairs with respect to email, anno 1990. > Back then customers started to notice that if they use their=20 > own domain for email, then they can switch providers without=20 > having to change their email address. Thus a *lot* of people=20 > opted to use their own domain for email. >=20 > My guess is that the same will happen to SIP. Once customers=20 > print their SIP uris on business cards, they will want to use=20 > their own domains. If providers won't support that feature=20 > then I suspect that the regulators will step in and mandate=20 > an URI portability solution just as they did in the PSTN with=20 > respect to numbers from number blocks. > (This could get really nasty protocol-wise, so I guess using=20 > customer- owned domains is the far better and likelier=20 > solution to the porting > question.) >=20 > So: Anything we come up with here in SPEERMINT needs to cope=20 > with a scenario where the use of customer domains in SIP URIs=20 > is just as widespread as it is for email.=20 I think this is a fair statement and probably worthwhile for inclusion, in some manner, in the upcoming requirements draft. I know I certainly see more similarities to the email domain model that anything else. I think you can roughly size the problem by, as you have done, looking at domain registrations and applying some penetration level to that (increasing over time). I would imagine, for example, any small business, enterprise, or university would want their own domain to be used in their public/published SIP URIs. (The unstated assumption is that we believe in the eventual ubiquity if public SIP URIs, as with email addresses 10+ years ago.) The records underlying a given SIP URI may refer to service provider names / elements, but I'd agree with you that these parties will want to continue using their own domains. Thus, we should not place a constraint on this problem that envisions the number of domains being roughly equal to the number of so-called carriers today. The number of domains will be much, much larger over time IMHO. Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 30 13:23:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl7w3-00044w-10; Tue, 30 May 2006 13:23:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl7w1-00044p-78 for speermint@ietf.org; Tue, 30 May 2006 13:23:13 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl7w0-0000Fo-FI for speermint@ietf.org; Tue, 30 May 2006 13:23:13 -0400 Received: from ([10.20.9.174]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.20650438; Tue, 30 May 2006 13:22:52 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 May 2006 13:22:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Defining Location Function (RE:UpdatedDraft:SPEERMINT Peering Architecture) Date: Tue, 30 May 2006 13:22:51 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96581DA2@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Defining Location Function (RE:UpdatedDraft:SPEERMINT Peering Architecture) Thread-Index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIAEEYoMAAEs7nCAACcsIAAAF4UfQAOV3R4AAcK35gAP5z0YAAA2P8gAAgEsSAABqXeoAAE631gACPh7OA= From: "Livingood, Jason" To: "Reinaldo Penno" X-OriginalArrivalTime: 30 May 2006 17:22:52.0249 (UTC) FILETIME=[AE6D7C90:01C6840D] X-Spam-Score: 0.0 (/) X-Scan-Signature: bc3b4a0e61e6c2546ab80acca7fc79df Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Those are good steps to capture in a draft. Perhaps eventually we'll see specific use case I-Ds that will consistently demonstrate out a need for each of these steps. Once we get some consensus there, that can inform the requirements draft now developing. Jason=20 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 > Sent: Monday, May 29, 2006 8:27 PM > To: richard@shockey.us; Khan, Sohel Q [CTO]; Stastny Richard > Cc: speermint@ietf.org > Subject: RE: [Speermint] Defining Location Function=20 > (RE:UpdatedDraft:SPEERMINT Peering Architecture) >=20 > Sohel, >=20 > I believe a VoIP-VoIP call have several stages: >=20 > 1. Location >=20 > How do I (domain A) discover where the proxy (which could be the final > one) to cross into domain B? There can be more than one in a=20 > certain location and even geographically dispersed locations. >=20 > 1.1 Policy exchange I >=20 > In determining domain's B crossing point, a policy=20 > query/exchange might happen. This might come in the form of=20 > DNS, a lookup on SUBSCRIPTION data or both >=20 > 2. Membership >=20 > After I discover domain's B proxy how to establish peering?=20 > Is it already established? Is it a federation? >=20 > This is what I call membership process. >=20 > 3. Policy exchange II >=20 > In a certain location where domain A and B peer, domain A's=20 > proxy might perform (another) policy exchange/query to find=20 > out which of domain's B several proxies is the best suited at=20 > that point in time.=20 >=20 > 4. Call establishment >=20 > Call gets established. >=20 > 5. Media >=20 > Media goes probably through the same path being marked=20 > according to the peering fabric's dscp. >=20 > Regards, >=20 > Reinaldo >=20 > > -----Original Message----- > > From: Richard Shockey [mailto:richard@shockey.us] > > Sent: Monday, May 29, 2006 2:54 PM > > To: 'Khan, Sohel Q [CTO]'; 'Stastny Richard' > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Defining Location Function (RE: > > UpdatedDraft:SPEERMINT Peering Architecture) > >=20 > >=20 > > NO .. that was called TRIP ( go do a RFC search) and no one in their > right > > mind wants to put a BGB like layer on VoIP routing. > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > > Sent: Monday, May 29, 2006 2:56 PM > > > To: Stastny Richard > > > Cc: speermint@ietf.org > > > Subject: [Speermint] Defining Location Function (RE: Updated=20 > > > Draft:SPEERMINT Peering Architecture) > > > > > > > > > Is it possible to take lessons from hierarchical eBGP routing? > > > We can consider each provider as the Autonomous System (say Level > 0), a > > > federation is a hierarchical Autonomous system (say Level 1) that=20 > > > contains a group of Autonomous-system (level 0). Hierarchical=20 > > > Autonomous system's (Level 1) SIP route-database (as=20 > opposed to the > BGP > > > routing table) is the Location Function (LF). SIP call routing > feature > > > will be destination-based, path-vector based, and policy based > similar > > > to BGP features. > > > I am trying to initiate a discussion in a different angle. > > > > > > Thanks, > > > > > > Sohel Khan, Ph.D. > > > Technology Strategist > > > Sprint-Nextel > > > 913-794-1470 (office) > > > 913-486-3145 (cell) > > > > > > > > > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Monday, May 29, 2006 10:06 AM > > > To: Khan, Sohel Q [CTO] > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > > > > > > Sohel, > > > > > > I posted this already on Friday, but I think everybody (including > me) > > > lost track already;-) > > > > > > So here once again: > > > > > > "May I try my summary: the Location function is a process=20 > containing=20 > > > eventually more then one step: > > > > > > "If you start with the CRD (e.g a SIP AoR entered by the User or > derived > > > from ENUM)" > > > > > > Remark: Whith this I ment that the E.164 to SIP URI mapping is > already > > > done, because this is out-of-scope of SPEERMINT. > > > In addition, SPEERMINT MUST be able to work in the same way if the > user > > > has entered a SIP URI direct. This is why I prefer that the result > of an > > > ENUM query is an AoR and not directly the ingress element to the=20 > > > destination network. > > > > > > > > > "1. The AoR gives you the destination network > > > > > > 2. You need to locate the peering club (=3D federation) for=20 > exchanging > SIP > > > messages (L5 )with the destination network > > > > > > 3. so you need to locate the policy you want to use and make a > decision > > > on the federation > > > (note: a destination network may belong to more then one > federations)" > > > (Remark: both origination network and destination network may be > members > > > of more then one federation. They may need to locate a common one. > If > > > more then one federation is in common, it is the choice of the=20 > > > origination network to select one - So the Policy Function is > embedded > > > in the LF) > > > > > > 4. "having chosen a federation, you need to locate the ingress > > > proxy(ies) the destination network is using within this=20 > federation. > > > > > > 5. If you are using a separate peering for exchanging=20 > media, you now > may > > > locate these" > > > > > > Additional remark: In step 4. and 5. some geographic=20 > location magic=20 > > > could come into play as requested by some on this list. > > > > > > Regards > > > Richard > > > > > > > -----Original Message----- > > > > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > > > Sent: Monday, May 29, 2006 4:30 PM > > > > To: Stastny Richard > > > > Cc: speermint@ietf.org > > > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > > > > > > > > Richard, > > > > > > > > Would you please describe what LF should perform (in your > opinion)? > > > > > > > > > > > > Thanks, > > > > > > > > Sohel > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Sunday, May 28, 2006 3:07 AM > > > > To: Khan, Sohel Q [CTO] > > > > Cc: speermint@ietf.org > > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > > > > > > > > I do not know how often I stated here that numbering=20 > issues (and=20 > > > > therefore also NUMBER Portability issues) are out-of-scope in > > > SPEERMINT > > > > > > > > So NUMBER Portablility cannot ne addressed in SPEERMINT LF > > > > > > > > Or we change the SPEERMINT charter > > > > > > > > Richard > > > > > > > > ________________________________ > > > > > > > > Von: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > > > Gesendet: So 28.05.2006 06:48 > > > > An: Stastny Richard; Reinaldo Penno > > > > Cc: speermint@ietf.org > > > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > > > > > > > > > > > > > > > > I think issues of mobility and number portability need to be > addressed > > > > > > > together in SPEERMINT LF. > > > > > > > > Sohel Khan, Ph.D. > > > > Sprint-Nextel > > > > > > > > -----Original Message----- > > > > From: "Stastny Richard" > > > > To: "Reinaldo Penno" > > > > Cc: "speermint@ietf.org" > > > > Sent: 5/27/06 4:52 PM > > > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > > > > > > > > What question? > > > > Richard > > > > > > > > ________________________________ > > > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > Gesendet: Sa 27.05.2006 23:46 > > > > An: Stastny Richard > > > > Cc: speermint@ietf.org > > > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > > > > > > > > > > > > > > > > Apart form your outside-of-the-us rhetoric the=20 > questions remains. > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Saturday, May 27, 2006 2:38 PM > > > > > To: Reinaldo Penno > > > > > Cc: speermint@ietf.org > > > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > > > Architecture > > > > > > > > > > ENUM issues should not be discussed in SPEERMINT, just some > > > questions > > > > > > > > > > >Enum? When I dial (650) 453 2312, what is there to resolve > _inside_ > > > > the > > > > > >wireless network that owns this number apart from=20 > the location > of > > > the > > > > > > > > > >user? > > > > > > > > > > and _outside_? > > > > > ENUM is about numbers like +16504532312 > > > > > > > > > > hello, we are talking E.164 numbers in ENUM, which is > international > > > > > numbers > > > > > > > > > > >Now, in the scenario where an external call (for example, a > > > cingular > > > > > >customer calling a Verizon customer (which owns an original > > > t-mobile > > > > > >number). How that works today? If you say ENUM I would stand > > > > corrected > > > > > >(and surprised), since LNP has been fully deployed=20 > since 2003. > > > > > > > > > > Cingular?Verizon? ... > > > > > > > > > > we are talking about a global solution here You are a bit US > centric > > > > > > > > here, there is also some 200 other nations ozt there. > > > > > > > > > > I have no access to the US LNP database from e.g. Austria > > > > > > > > > > So you want to consider US national databases only in=20 > speermint? > > > > > > > > > > Richard > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > Gesendet: Sa 27.05.2006 21:30 > > > > > An: Stastny Richard; Otmar Lendl > > > > > Cc: speermint@ietf.org > > > > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering > > > Architecture > > > > > > > > > > > > > > > > > > > > Enum? When I dial (650) 453 2312, what is there to resolve > _inside_ > > > > the > > > > > wireless network that owns this number apart from the location > of > > > the > > > > > user? > > > > > > > > > > > > > > > Now, in the scenario where an external call (for example, a > cingular > > > > > > > > customer calling a Verizon customer (which owns an original > t-mobile > > > > > > > > number). How that works today? If you say ENUM I would stand > > > corrected > > > > > > > > > (and surprised), since LNP has been fully deployed since 2003. > > > > > > > > > > When a user takes its number with them, I assumed=20 > this punches a > > > whole > > > > > > > > > in the telephone prefix hierarchy and a specific=20 > entry somewhere > is > > > > > needed. > > > > > > > > > > Regards, > > > > > > > > > > Reinaldo > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > > Sent: Saturday, May 27, 2006 4:26 AM > > > > > > To: Reinaldo Penno; Otmar Lendl > > > > > > Cc: speermint@ietf.org > > > > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > > > > Architecture > > > > > > > > > > > > >I wonder how > > > > > > >LNP is solved within wireless...A specific entry for each > phone? > > > > That > > > > > > >would be crazy. > > > > > > > > > > > > Ahem, ENUM? > > > > > > > > > > > > I thought that is all what ENUM is about? > > > > > > > > > > > > Richard > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > Gesendet: Sa 27.05.2006 11:04 > > > > > > An: Otmar Lendl; Patrick Melampy > > > > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org > > > > > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering > > > > Architecture > > > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > I believe the crux of the problem was missed. > > > > > > > > > > > > The issue is not really the number of domains. We have today > some > > > > > > 400.000.000 million hosts on the Internet. BGP=20 > peers to do not > > > > > exchange > > > > > > 400.000.000 million routes, they exchange in the=20 > low hundreds > of > > > > > > thousands. > > > > > > > > > > > > And why is that? (I guess you know where I'm getting at). > That's > > > > > because > > > > > > IP addresses lend themselves very well to hierarchical > deployment, > > > > > > > > > compression through prefix/CIDR usage and the like.=20 > DNS names > are > > > > > > strings and hence difficult to come up with a=20 > similar scheme. > > > > > > > > > > > > > > > > > > I believe that if domains need to be exchanged=20 > between peers: > > > > > > > > > > > > 1 - Just a limited set would be exchanged and a=20 > "default layer > 5 > > > > > route" > > > > > > (equivalent to a traditional default route) would be used. > > > > > > > > > > > > 2 - Compression schemes like *.company.com, regular > expressions or > > > > the > > > > > > like would need to be used. Having specific routes to AORs > would > > > be > > > > > > hairy (maybe for the eventual roaming or visiting user). I > wonder > > > > how > > > > > > LNP is solved within wireless...A specific entry for each > phone? > > > > That > > > > > > would be crazy. > > > > > > > > > > > > 3 - Some new scheme that will make somebody rich....until > then.. > > > > > > > > > > > > I believe subscriptions would be used to exchange mostly > "cost" > > > and > > > > > > policy information and some domains. I use cost here in the > layer > > > 3 > > > > > > sense (number of calls, jitter, whatever). Cost would be an > > > abstract > > > > > > > > > > value or a more specific one (up to the administrator). > > > > > > > > > > > > Regards, > > > > > > > > > > > > Reinaldo > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > > > > > Sent: Saturday, May 27, 2006 1:29 AM > > > > > > > To: Patrick Melampy > > > > > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > > > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > > > > > Architecture > > > > > > > > > > > > > > On 2006/05/26 18:05, Patrick Melampy > > > > > > wrote: > > > > > > > > I suppose like in any distributed routing=20 > protocol, there > are > > > > some > > > > > > > chicken > > > > > > > > an egg issues. But consider the following. > > > > > > > > > > > > > > > > PREREQUISITES: > > > > > > > > 1.) You know the destination DOMAIN from either ENUM or > other > > > > > means. > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > > This technique is very similar to TRIP, only its for > DOMAINS > > > and > > > > > not > > > > > > > partial > > > > > > > > E.164 numbers. > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > Obviously, the data set could get large, as the list of > > > domains > > > > > can > > > > > > be > > > > > > > > really big. There are some possibilities here... > > > > > > > > > > > > > > Let's do a quick estimate on the number of=20 > domains involved: > > > > > > > > > > > > > > Right now, operators usually give customers URIs=20 > of the form=20 > > > > > > > @. As long as this is the state of > > > > affairs, > > > > > > > we're fine as the number of providers is quite=20 > finite (a few=20 > > > > > > > thousands, perhaps). > > > > > > > > > > > > > > This is like the state of affairs with respect to email, > anno > > > > 1990. > > > > > > > Back then customers started to notice that if=20 > they use their > own > > > > > > domain > > > > > > > for email, then they can switch providers without=20 > having to > > > change > > > > > > > > > > > their email address. Thus a *lot* of people opted to use > their > > > own > > > > > > > > > > > domain for email. > > > > > > > > > > > > > > My guess is that the same will happen to SIP.=20 > Once customers > > > print > > > > > > > > > > > their SIP uris on business cards, they will want to use > their > > > own > > > > > > > domains. If providers won't support that feature then I > suspect > > > > that > > > > > > > the regulators will step in and mandate an URI portability > > > > solution > > > > > > > just as they did in the PSTN with respect to numbers from > number > > > > > > blocks. > > > > > > > (This could get really nasty protocol-wise, so I=20 > guess using > > > > > customer- > > > > > > > owned domains is the far better and likelier=20 > solution to the > > > > porting > > > > > > > question.) > > > > > > > > > > > > > > So: Anything we come up with here in SPEERMINT=20 > needs to cope > > > with > > > > a > > > > > > > scenario where the use of customer domains in SIP URIs is > just > > > as > > > > > > > widespread as it is for email. > > > > > > > > > > > > > > How many domains are used for email? That's hard to say. > There > > > are > > > > > > > > > > > about 60 million gTLD domains and probably more than 20 > ccTLD > > > > ones. > > > > > > > Assuming that only a tenth of that is used for email we're > at > > > > > > > 8 million domains. Given the exponential growth any system > which > > > > > > > > > > doesn't scale to at least 10 million domains will be > obsolete > > > > before > > > > > > > the ink is dry on the RFC. > > > > > > > > > > > > > > So what happens if we do some sort of BGP or TRIP with > domains? > > > > > > > > > > > > > > Let's say we need at least 100 bytes of state information > per > > > > > domain. > > > > > > > That makes a full routing table 1 GB worth of data. That > also > > > > means > > > > > > > that a new border element needs to exchange that amount of > data > > > > > > > with its peers before it has learned the current state of > the > > > > > > > routing table. > > > > > > > > > > > > > > That is some serious amount of data. > > > > > > > > > > > > > > > 1.) Have notification point to a published document, and > the > > > > > > document > > > > > > > lists > > > > > > > > all of the relevant reachability in real time. Thus any > change > > > > to > > > > > > the > > > > > > > > document would generate a NOTIFICATION. > > > > > > > > > > > > > > + a download of up to 1 GB per peer. > > > > > > > > > > > > > > > 2.) User partial domains, broken up by the "dots". This > may > > > > allow > > > > > > some > > > > > > > > wildcarding to reduce the number of domains.=20 > For instance, > a > > > > > carrier > > > > > > > like > > > > > > > > Verizon may have many 100's of domains attached=20 > to it, and > > > > version > > > > > > is > > > > > > > > willing to route and manage SIP traffic to any of them. > The > > > > NOTIFY > > > > > > could > > > > > > > > contain something like: Verizon.com or *.verizon.com to > > > indicate > > > > > > that > > > > > > > any > > > > > > > > domain in Verizon is reachable. > > > > > > > > > > > > > > That's helpful if a provider uses subdomains for internal > > > > purposes, > > > > > > > but that won't help you with customer owned domains. > > > > > > > > > > > > > > > This technique may work -- and fit nicely into=20 > an existing > > > > > protocol. > > > > > > All > > > > > > > we > > > > > > > > would need to do is define the data models (XML?) and or > > > > documents > > > > > > for > > > > > > > > exchanging. > > > > > > > > > > > > > > I think this technique can work -- if you add an=20 > aggregation > > > step > > > > > > > before the routing scheme. > > > > > > > > > > > > > > Take another look at BGP: there you have the=20 > concept of an=20 > > > > > > > Autonomous System and not only that of prefixes. Maybe you > need > > > > > > > something similar. > > > > > > > > > > > > > > One approach to cope with hosted SIP domains=20 > could be to use > the > > > > > > > > > > hostnames as found in SRV records. E.g. for settings like > > > > > > > > > > > > > > _sip._tcp.customer.domain IN SRV 10 10 5060=20 > sip.provider.com > > > > > > > > > > > > > > run the routing algorithm on "sip.provider.com"=20 > instead of=20 > > > > > > > "customer.domain". > > > > > > > > > > > > > > Another option is to store some AS-equivalent in the > customer > > > > domain > > > > > > > and have the routing algorithm operate on that. In my > > > > domain-policy > > > > > > > framework this could be expressed e.g. like > > > > > > > > > > > > > > customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > > > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > > > > > > > > > stating that this domain can be reached using the=20 > Speermint > > > > routing > > > > > > > logic by using the learned route to RoutingID 1042. > > > > > > > > > > > > > > Or, even better, use non-terminals, and thus refer to the > > > ingress > > > > > > > policy stored in the provider's domain: > > > > > > > > > > > > > > customers.domain IN NAPTR "" 10 10 "D2P+SIP" ""=20 > provider.com > > > > > > > > > > > > > > provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > > > > > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > > > > > > > > > > > (+ whatever other facts provider.com wants to=20 > announce about > his > > > > > > > reachability.) > > > > > > > > > > > > > > This combination of our ideas can indeed work and scale to > an > > > > > > > unlimited number of customer-owned domains. > > > > > > > > > > > > > > /ol > > > > > > > -- > > > > > > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Speermint mailing list > > > > > > > Speermint@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > _______________________________________________ > > > > > > Speermint mailing list > > > > > > Speermint@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 30 13:28:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl80t-0005d2-Dw; Tue, 30 May 2006 13:28:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl80r-0005cx-W6 for speermint@ietf.org; Tue, 30 May 2006 13:28:13 -0400 Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl80q-0000d4-Ie for speermint@ietf.org; Tue, 30 May 2006 13:28:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 30 May 2006 13:27:53 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96581DA3@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaBcygQnA3VO3/dRmScoe3KFSCrBQCboabQAAsHKSA= From: "Livingood, Jason" To: "Brian Rosen" X-OriginalArrivalTime: 30 May 2006 17:27:53.0807 (UTC) FILETIME=[622B95F0:01C6840E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > I believe this discussion has gone over the edge. >=20 > The reason SPEERMINT exists is that CARRIERS want to peer. Perhaps a fair assessment, but I suspect we all would like it to progress beyond that. =20 =20 > Email is an inappropriate metaphor for carrier peering. Perhaps but I don't think we can conclude that as yet. There are most definitely differences though. I see no reason not to try to take some of the simplicity and ubiquity of that model and trying to apply it to a new application where it makes sense. > Email and normal SIP routing are approximately the same: > Generally speaking, a domain accepts mail (calls) from=20 > any domain > The mail (call) is marked by the sender with the domain=20 > of the recipient > Mail (calls) is (are) exchanged over the open Internet > You find the mail (sip) server by looking at the DNS entry=20 > for the domain Yup... =20 > I expect that some day, that IS the way we will do calls, but=20 > right now, carriers get paid to make calls work, and they=20 > want closed communities. And most carriers will continue using the PSTN for that, IMHO. Also IMHO is that when those entities look to move beyond closed communities (and today's vision of a voice application) that a speermint type of model is more interesting. > At any point, a carrier or any other domain can just take a=20 > SIP URI and route it with normal RFC3261 routing to its=20 > destination URI. It's probably not the originating domain=20 > that cares, it's the terminating domain. >=20 > As Richard points out rather frequently, SPEERMINT does not=20 > deal with E.164s, it deals with SIP URIs. They have the=20 > domain, but in SPEERMINT, we need something other than an SRV=20 > entry for the domain to be able to terminate it. >=20 > Some day, we'll just do domain to domain calls, just like=20 > email, but that is not what SPEERMINT deals with. >=20 > Brian >=20 > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Saturday, May 27, 2006 5:51 AM > To: Reinaldo Penno > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > On 2006/05/27 11:05, Reinaldo Penno wrote: > >=20 > > I believe the crux of the problem was missed. > >=20 > > The issue is not really the number of domains. We have today some=20 > > 400.000.000 million hosts on the Internet. BGP peers to do not=20 > > exchange 400.000.000 million routes, they exchange in the=20 > low hundreds=20 > > of thousands. > >=20 > > And why is that? (I guess you know where I'm getting at). That's=20 > > because IP addresses lend themselves very well to hierarchical=20 > > deployment, compression through prefix/CIDR usage and the like. DNS=20 > > names are strings and hence difficult to come up with a=20 > similar scheme. >=20 > That's because IP-addresses, are, eh, addresses. Routing information. > They are (ignoring PI space / multihoming for the moment)=20 > provider- dependent and if you change provider you will also=20 > get new IP-addresses. >=20 > Domains are NAMES. Not addresses. You usually own your domain=20 > and take it with you if you switch email provider or=20 > web-hoster. Domains itself contain NO ROUTING INFORMATION.=20 > Their hierarchical structure reflects the delegation chain=20 > but in no way L3 or application layer routing. >=20 > I can host the webspace of my lendl.priv.at domain anywhere=20 > in the world, using any provider that sells webspace. The .at=20 > is no guarantee at all that the webserver is located in Austria. >=20 > The DNS is used to map Domain NAMES to ADDRESSES which=20 > contain routing information. >=20 > Any routing schema which operates on names is per definition=20 > not suitable for aggregation, because names are independent=20 > of network topology. >=20 > > I believe that if domains need to be exchanged between peers: > >=20 > > 1 - Just a limited set would be exchanged and a "default=20 > layer 5 route" > > (equivalent to a traditional default route) would be used. >=20 > This leads to suboptimal routing (e.g. consider nic.at calling > vienna.ibm.com) and doesn't absolve the core networks from=20 > running a full routing table. >=20 > > 2 - Compression schemes like *.company.com, regular=20 > expressions or the=20 > > like would need to be used. Having specific routes to AORs would be=20 > > hairy (maybe for the eventual roaming or visiting user). I=20 > wonder how=20 > > LNP is solved within wireless...A specific entry for each=20 > phone? That=20 > > would be crazy. >=20 > I guess the Richards on this list can give you some details=20 > on that. But from all I know most LNP solutions require the=20 > exchange of at least one routing record per ported number.=20 > (Other solutions do onward routing, there the call traverses=20 > through the donor network. Yuck.) >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 30 13:51:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl8Mq-0004os-7a; Tue, 30 May 2006 13:50:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl8Mp-0004on-D2 for speermint@ietf.org; Tue, 30 May 2006 13:50:55 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl8Mo-0004As-3m for speermint@ietf.org; Tue, 30 May 2006 13:50:55 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 8B09C1A379; Tue, 30 May 2006 19:50:40 +0200 (CEST) Date: Tue, 30 May 2006 19:50:40 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Message-ID: <20060530175040.GP1811@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <4884CD6C1DF0A8429DD8DAD942BF9D96581DA3@PACDCEXCMB03.cable.comcast.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4884CD6C1DF0A8429DD8DAD942BF9D96581DA3@PACDCEXCMB03.cable.comcast.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/05/30 19:05, "Livingood, Jason" wrote: > > I believe this discussion has gone over the edge. > > > > The reason SPEERMINT exists is that CARRIERS want to peer. > > Perhaps a fair assessment, but I suspect we all would like it to > progress beyond that. > > > Email is an inappropriate metaphor for carrier peering. > > Perhaps but I don't think we can conclude that as yet. There are most > definitely differences though. I see no reason not to try to take some > of the simplicity and ubiquity of that model and trying to apply it to a > new application where it makes sense. My take is that we need a system that * allows selective peering. If we require that everybody can talk directly to everybody else, we don't get carrier opt-in. * supports branching off into private interconnects. Ideally, all the existing private peering fabrics should fit into the speermint umbrella. * scales to wide adoption, both for SIP URIs / domains as well as peering operators. Nothing in the protocol should preclude that it is used e.g. to get VoIP-enabled PBX systems to peer with each other. (Whether a carrier wants to peer with a PBX is his choice. The protocol shouldn't dictate a peering policy. The contrary: the protocol must support all possible peering policies.) * gives BCPs on how to do the nitty-gritty SIP details (caller-ID, privacy, ...) /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 30 15:54:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlAIQ-00082d-J2; Tue, 30 May 2006 15:54:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlAI7-0007sE-2u for speermint@ietf.org; Tue, 30 May 2006 15:54:11 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlAI7-0007b9-1Q for speermint@ietf.org; Tue, 30 May 2006 15:54:11 -0400 Received: from qfe1.f10207-20.atlanta2.level3.net ([67.72.93.25] helo=f10207-20.adc1.level3.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlA9j-0001Se-PD for speermint@ietf.org; Tue, 30 May 2006 15:45:33 -0400 Received: from machine77.Level3.com (qfe0.f10212-07.adc1.oss.level3.com [10.2.1.102]) by f10207-20.adc1.level3.com (8.12.10/8.12.10) with ESMTP id k4UJj36r021150; Tue, 30 May 2006 19:45:18 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id 9212D12482D; Tue, 30 May 2006 19:45:02 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner5.level3.com (Postfix) with SMTP id 1D68212480D; Tue, 30 May 2006 19:45:02 +0000 (GMT) Received: from idc1exc0006.corp.global.level3.com ([10.1.9.17]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 May 2006 13:44:59 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 30 May 2006 13:44:59 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaEEdBAV/nhiie0SOG4l7wbr22a4gADATtA From: "Malas, Daryl" To: "Otmar Lendl" , X-OriginalArrivalTime: 30 May 2006 19:44:59.0805 (UTC) FILETIME=[893F44D0:01C68421] X-Spam-Score: -1.5 (-) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org In addition to your comments below, I think peering will likely occur in one of the following methods or all of them (this includes the capabilities described in the Peering Architecture Draft: =20 +---------+ | | +--------+ +--------+ +------------+ /|Domain C |=20 | | | | / \ / | | |Domain A| Private |Domain B| Public | Internet |/ +---------+ | |=3D=3D=3D=3D=3D=3D=3D=3D=3D| = |=3D=3D=3D=3D=3D=3D=3D=3D=3D| |\ | | Peer | | Peer \ / \ +---------+ +--------+ +--------+ +------------+ \| | || |Domain D |=09 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D| |=09 Private Peer +---------+ As far as PBX interconnect goes... I don't think SPEERMINT should design a tie-line replacement architecture. IMO, it is out of scope. I know this becomes somewhat blurry, as more SIP PBX's are a conglomeration of multiple SIP capabilities (e.g. UA, UAS, Proxy, etc.), some of which are described in the architecture. However, the SIP Forum is already addressing many of those concerns in SIP Forum drafts such as: sf-draft-twg-IP_PBX_SP_Interop-sibley-v5.pdf. My two cents... =09 --Daryl M. -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at]=20 Sent: Tuesday, May 30, 2006 11:51 AM To: speermint@ietf.org Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture On 2006/05/30 19:05, "Livingood, Jason" wrote: > > I believe this discussion has gone over the edge. > >=20 > > The reason SPEERMINT exists is that CARRIERS want to peer. >=20 > Perhaps a fair assessment, but I suspect we all would like it to > progress beyond that. =20 > =20 > > Email is an inappropriate metaphor for carrier peering. >=20 > Perhaps but I don't think we can conclude that as yet. There are most > definitely differences though. I see no reason not to try to take some > of the simplicity and ubiquity of that model and trying to apply it to a > new application where it makes sense. My take is that we need a system that * allows selective peering. If we require that everybody can talk directly to everybody else, we don't get carrier opt-in. * supports branching off into private interconnects. Ideally, all the existing private peering fabrics should fit into the speermint umbrella. * scales to wide adoption, both for SIP URIs / domains as well as peering operators. Nothing in the protocol should preclude that it is used e.g. to get VoIP-enabled PBX systems to peer with each other. (Whether a carrier wants to peer with a PBX is his choice.=20 The protocol shouldn't dictate a peering policy. The contrary: the protocol must support all possible peering policies.) * gives BCPs on how to do the nitty-gritty SIP details (caller-ID, privacy, ...) /ol --=20 < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 30 16:02:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlAPn-0002gu-Id; Tue, 30 May 2006 16:02:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlAPm-0002gp-JA for speermint@ietf.org; Tue, 30 May 2006 16:02:06 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlAPl-0008PD-8A for speermint@ietf.org; Tue, 30 May 2006 16:02:06 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FlAPR-0001rS-9H; Tue, 30 May 2006 15:01:45 -0500 From: "Brian Rosen" To: "'Malas, Daryl'" , "'Otmar Lendl'" , Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 30 May 2006 16:01:46 -0400 Message-ID: <04c901c68423$e4b5a870$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaEEdBAV/nhiie0SOG4l7wbr22a4gADATtAAAFX9mA= X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I am absolutely certain that these kinds of arrangements will be seen "in the wild". Two thoughts strike me: 1) If Domain A is paying Domain B a lot for this kind of service, it may need a software update so it can do it itself 2) The route advertisement from B towards A gets REALLY tricky. The reason is that there is no convenient way to express it. It's not "*" (I can get you to any domain). It's "I can get you to any domain that accepts connections from the Internet". It's the terminating network that decides if it will allow traffic from some other domain, and "Domain B" below, doesn't know what the rules for Domain C are. Brian -----Original Message----- From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] Sent: Tuesday, May 30, 2006 3:45 PM To: Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture In addition to your comments below, I think peering will likely occur in one of the following methods or all of them (this includes the capabilities described in the Peering Architecture Draft: +---------+ | | +--------+ +--------+ +------------+ /|Domain C | | | | | / \ / | | |Domain A| Private |Domain B| Public | Internet |/ +---------+ | |=========| |=========| |\ | | Peer | | Peer \ / \ +---------+ +--------+ +--------+ +------------+ \| | || |Domain D | =======================================================| | Private Peer +---------+ As far as PBX interconnect goes... I don't think SPEERMINT should design a tie-line replacement architecture. IMO, it is out of scope. I know this becomes somewhat blurry, as more SIP PBX's are a conglomeration of multiple SIP capabilities (e.g. UA, UAS, Proxy, etc.), some of which are described in the architecture. However, the SIP Forum is already addressing many of those concerns in SIP Forum drafts such as: sf-draft-twg-IP_PBX_SP_Interop-sibley-v5.pdf. My two cents... --Daryl M. -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at] Sent: Tuesday, May 30, 2006 11:51 AM To: speermint@ietf.org Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture On 2006/05/30 19:05, "Livingood, Jason" wrote: > > I believe this discussion has gone over the edge. > > > > The reason SPEERMINT exists is that CARRIERS want to peer. > > Perhaps a fair assessment, but I suspect we all would like it to > progress beyond that. > > > Email is an inappropriate metaphor for carrier peering. > > Perhaps but I don't think we can conclude that as yet. There are most > definitely differences though. I see no reason not to try to take some > of the simplicity and ubiquity of that model and trying to apply it to a > new application where it makes sense. My take is that we need a system that * allows selective peering. If we require that everybody can talk directly to everybody else, we don't get carrier opt-in. * supports branching off into private interconnects. Ideally, all the existing private peering fabrics should fit into the speermint umbrella. * scales to wide adoption, both for SIP URIs / domains as well as peering operators. Nothing in the protocol should preclude that it is used e.g. to get VoIP-enabled PBX systems to peer with each other. (Whether a carrier wants to peer with a PBX is his choice. The protocol shouldn't dictate a peering policy. The contrary: the protocol must support all possible peering policies.) * gives BCPs on how to do the nitty-gritty SIP details (caller-ID, privacy, ...) /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 30 16:03:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlAQg-0002yO-PM; Tue, 30 May 2006 16:03:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlAQf-0002yJ-7W for speermint@ietf.org; Tue, 30 May 2006 16:03:01 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlAQd-0008Q3-T1 for speermint@ietf.org; Tue, 30 May 2006 16:03:01 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 30 May 2006 13:02:59 -0700 X-IronPort-AV: i="4.05,190,1146466800"; d="scan'208"; a="550419091:sNHT34596020" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 30 May 2006 16:02:57 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280483E60E@proton.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaEEdBAV/nhiie0SOG4l7wbr22a4gADATtAAAGGBKA= From: "Reinaldo Penno" To: "Malas, Daryl" , "Otmar Lendl" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: "Khan, Sohel Q \[CTO\]" , "Uzelac, Adam" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I guess we should work on updating both draft (Architecture and Call flows). There are lots of new material to include. > -----Original Message----- > From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] > Sent: Tuesday, May 30, 2006 12:45 PM > To: Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > In addition to your comments below, I think peering will likely occur in > one of the following methods or all of them (this includes the > capabilities described in the Peering Architecture Draft: >=20 >=20 > +---------+ > | | > +--------+ +--------+ +------------+ /|Domain C | > | | | | / \ / | > | > |Domain A| Private |Domain B| Public | Internet |/ +---------+ > | |=3D=3D=3D=3D=3D=3D=3D=3D=3D| = |=3D=3D=3D=3D=3D=3D=3D=3D=3D| |\ > | | Peer | | Peer \ / \ +---------+ > +--------+ +--------+ +------------+ \| | > || > |Domain D | > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D| | > Private Peer > +---------+ >=20 >=20 > As far as PBX interconnect goes... >=20 > I don't think SPEERMINT should design a tie-line replacement > architecture. IMO, it is out of scope. I know this becomes somewhat > blurry, as more SIP PBX's are a conglomeration of multiple SIP > capabilities (e.g. UA, UAS, Proxy, etc.), some of which are described in > the architecture. However, the SIP Forum is already addressing many of > those concerns in SIP Forum drafts such as: > sf-draft-twg-IP_PBX_SP_Interop-sibley-v5.pdf. >=20 > My two cents... >=20 >=20 > --Daryl M. >=20 >=20 > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Tuesday, May 30, 2006 11:51 AM > To: speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > On 2006/05/30 19:05, "Livingood, Jason" > wrote: > > > I believe this discussion has gone over the edge. > > > > > > The reason SPEERMINT exists is that CARRIERS want to peer. > > > > Perhaps a fair assessment, but I suspect we all would like it to > > progress beyond that. > > > > > Email is an inappropriate metaphor for carrier peering. > > > > Perhaps but I don't think we can conclude that as yet. There are most > > definitely differences though. I see no reason not to try to take > some > > of the simplicity and ubiquity of that model and trying to apply it to > a > > new application where it makes sense. >=20 > My take is that we need a system that >=20 > * allows selective peering. If we require that everybody can talk > directly to everybody else, we don't get carrier opt-in. >=20 > * supports branching off into private interconnects. >=20 > Ideally, all the existing private peering fabrics should fit > into the speermint umbrella. >=20 > * scales to wide adoption, both for SIP URIs / domains as well as > peering operators. >=20 > Nothing in the protocol should preclude that it is used e.g. > to get VoIP-enabled PBX systems to peer with each other. >=20 > (Whether a carrier wants to peer with a PBX is his choice. > The protocol shouldn't dictate a peering policy. The contrary: > the protocol must support all possible peering policies.) >=20 > * gives BCPs on how to do the nitty-gritty SIP details > (caller-ID, privacy, ...) >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 30 16:20:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlAh7-00008U-NH; Tue, 30 May 2006 16:20:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlAh6-00008F-DG for speermint@ietf.org; Tue, 30 May 2006 16:20:00 -0400 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FlAh2-0000Hx-SZ for speermint@ietf.org; Tue, 30 May 2006 16:20:00 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-4.tower-126.messagelabs.com!1149020373!12277234!7 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 14800 invoked from network); 30 May 2006 20:19:55 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-4.tower-126.messagelabs.com with SMTP; 30 May 2006 20:19:55 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 44708FE90013523A; Tue, 30 May 2006 16:19:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 30 May 2006 16:19:53 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0CE78778@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <04c901c68423$e4b5a870$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaEEdBAV/nhiie0SOG4l7wbr22a4gADATtAAAFX9mAAAJ5/MA== From: "Pfautz, Penn L, GBLAM" To: "Brian Rosen" , "Malas, Daryl" , "Otmar Lendl" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Sorry, sent too soon... This is the kind of thing that makes we wonder why anyone wants to look at this in terms of route advertisement where A doesn't know the destination is C and just looks at what B says it can reach. I can imagine that A knows the ultimate destination is C and then seeks a route to C, which would eliminate the contradictions Brian raises. =20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, May 30, 2006 4:02 PM To: 'Malas, Daryl'; 'Otmar Lendl'; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture I am absolutely certain that these kinds of arrangements will be seen "in the wild". Two thoughts strike me: 1) If Domain A is paying Domain B a lot for this kind of service, it may need a software update so it can do it itself 2) The route advertisement from B towards A gets REALLY tricky. The reason is that there is no convenient way to express it. It's not "*" (I can get you to any domain). It's "I can get you to any domain that accepts connections from the Internet". It's the terminating network that decides if it will allow traffic from some other domain, and "Domain B" below, doesn't know what the rules for Domain C are. Brian -----Original Message----- From: Malas, Daryl [mailto:Daryl.Malas@Level3.com]=20 Sent: Tuesday, May 30, 2006 3:45 PM To: Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture In addition to your comments below, I think peering will likely occur in one of the following methods or all of them (this includes the capabilities described in the Peering Architecture Draft: =20 +---------+ | | +--------+ +--------+ +------------+ /|Domain C |=20 | | | | / \ / | | |Domain A| Private |Domain B| Public | Internet |/ +---------+ | |=3D=3D=3D=3D=3D=3D=3D=3D=3D| = |=3D=3D=3D=3D=3D=3D=3D=3D=3D| |\ | | Peer | | Peer \ / \ +---------+ +--------+ +--------+ +------------+ \| | || |Domain D |=09 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D| |=09 Private Peer +---------+ As far as PBX interconnect goes... I don't think SPEERMINT should design a tie-line replacement architecture. IMO, it is out of scope. I know this becomes somewhat blurry, as more SIP PBX's are a conglomeration of multiple SIP capabilities (e.g. UA, UAS, Proxy, etc.), some of which are described in the architecture. However, the SIP Forum is already addressing many of those concerns in SIP Forum drafts such as: sf-draft-twg-IP_PBX_SP_Interop-sibley-v5.pdf. My two cents... =09 --Daryl M. -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at]=20 Sent: Tuesday, May 30, 2006 11:51 AM To: speermint@ietf.org Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture On 2006/05/30 19:05, "Livingood, Jason" wrote: > > I believe this discussion has gone over the edge. > >=20 > > The reason SPEERMINT exists is that CARRIERS want to peer. >=20 > Perhaps a fair assessment, but I suspect we all would like it to > progress beyond that. =20 > =20 > > Email is an inappropriate metaphor for carrier peering. >=20 > Perhaps but I don't think we can conclude that as yet. There are most > definitely differences though. I see no reason not to try to take some > of the simplicity and ubiquity of that model and trying to apply it to a > new application where it makes sense. My take is that we need a system that * allows selective peering. If we require that everybody can talk directly to everybody else, we don't get carrier opt-in. * supports branching off into private interconnects. Ideally, all the existing private peering fabrics should fit into the speermint umbrella. * scales to wide adoption, both for SIP URIs / domains as well as peering operators. Nothing in the protocol should preclude that it is used e.g. to get VoIP-enabled PBX systems to peer with each other. (Whether a carrier wants to peer with a PBX is his choice.=20 The protocol shouldn't dictate a peering policy. The contrary: the protocol must support all possible peering policies.) * gives BCPs on how to do the nitty-gritty SIP details (caller-ID, privacy, ...) /ol --=20 < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 30 17:03:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlBMw-0005fQ-KI; Tue, 30 May 2006 17:03:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlBMv-0005fL-Lg for speermint@ietf.org; Tue, 30 May 2006 17:03:13 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlBMu-0003Bb-7L for speermint@ietf.org; Tue, 30 May 2006 17:03:13 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FlBMW-000687-C0; Tue, 30 May 2006 16:02:48 -0500 From: "Brian Rosen" To: "'Pfautz, Penn L, GBLAM'" , "'Malas, Daryl'" , "'Otmar Lendl'" , Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 30 May 2006 17:02:52 -0400 Message-ID: <04d901c6842c$6c63b8e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0CE78778@ACCLUST02EVS1.ugd.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaEEdBAV/nhiie0SOG4l7wbr22a4gADATtAAAFX9mAAAJ5/MAABDMqQ X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Perhaps we are misinterpreting the figure. I am interpreting C as accepting calls over the Internet from any domain (that is, not limited to specific peers). I'm not just thinking that the peering fabric is the Internet; of course any connection between peers can traverse the Internet. I assume A knows it wants a route to C. ENUM is out of scope. The Route Advertisement is what domains B tells A it can get to, so that A knows B can get to C. Contradiction 1 is that if C is known to accept connections from any domain, then B is not adding value. It can't be a secret only known to B that C accepts any connections. Contradiction 2 is that B can't tell A that it can reach all possible C's. A specific C, maybe, but then you are back to Contradiction 1. Let's be more concrete. Suppose there is an enterprise with a SIP PBX. Suppose it starts out by purchasing VoIP termination services from a carrier and sends all its traffic there, and to start, only accepts traffic from its carrier. Now, suppose that at some point the enterprise gets comfortable and starts allowing traffic from the Internet direct to its PBX. Suppose, just to get it off the table, that there is public ENUM, so number services are not an issue. This enterprise is now a "C". How does B tell A that it can get to C? How does it know that? Generally, C freely "advertises" its "route" by simply putting an SRV record in its public DNS. What is the way A "seeks a route to C" by any mechanism short of just trying DNS. What I'm getting at is that B can't make a definitive list of all the C's out there, and there is no wildcard that works. Brian -----Original Message----- From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] Sent: Tuesday, May 30, 2006 4:20 PM To: Brian Rosen; Malas, Daryl; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Sorry, sent too soon... This is the kind of thing that makes we wonder why anyone wants to look at this in terms of route advertisement where A doesn't know the destination is C and just looks at what B says it can reach. I can imagine that A knows the ultimate destination is C and then seeks a route to C, which would eliminate the contradictions Brian raises. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, May 30, 2006 4:02 PM To: 'Malas, Daryl'; 'Otmar Lendl'; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture I am absolutely certain that these kinds of arrangements will be seen "in the wild". Two thoughts strike me: 1) If Domain A is paying Domain B a lot for this kind of service, it may need a software update so it can do it itself 2) The route advertisement from B towards A gets REALLY tricky. The reason is that there is no convenient way to express it. It's not "*" (I can get you to any domain). It's "I can get you to any domain that accepts connections from the Internet". It's the terminating network that decides if it will allow traffic from some other domain, and "Domain B" below, doesn't know what the rules for Domain C are. Brian -----Original Message----- From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] Sent: Tuesday, May 30, 2006 3:45 PM To: Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture In addition to your comments below, I think peering will likely occur in one of the following methods or all of them (this includes the capabilities described in the Peering Architecture Draft: +---------+ | | +--------+ +--------+ +------------+ /|Domain C | | | | | / \ / | | |Domain A| Private |Domain B| Public | Internet |/ +---------+ | |=========| |=========| |\ | | Peer | | Peer \ / \ +---------+ +--------+ +--------+ +------------+ \| | || |Domain D | =======================================================| | Private Peer +---------+ As far as PBX interconnect goes... I don't think SPEERMINT should design a tie-line replacement architecture. IMO, it is out of scope. I know this becomes somewhat blurry, as more SIP PBX's are a conglomeration of multiple SIP capabilities (e.g. UA, UAS, Proxy, etc.), some of which are described in the architecture. However, the SIP Forum is already addressing many of those concerns in SIP Forum drafts such as: sf-draft-twg-IP_PBX_SP_Interop-sibley-v5.pdf. My two cents... --Daryl M. -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at] Sent: Tuesday, May 30, 2006 11:51 AM To: speermint@ietf.org Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture On 2006/05/30 19:05, "Livingood, Jason" wrote: > > I believe this discussion has gone over the edge. > > > > The reason SPEERMINT exists is that CARRIERS want to peer. > > Perhaps a fair assessment, but I suspect we all would like it to > progress beyond that. > > > Email is an inappropriate metaphor for carrier peering. > > Perhaps but I don't think we can conclude that as yet. There are most > definitely differences though. I see no reason not to try to take some > of the simplicity and ubiquity of that model and trying to apply it to a > new application where it makes sense. My take is that we need a system that * allows selective peering. If we require that everybody can talk directly to everybody else, we don't get carrier opt-in. * supports branching off into private interconnects. Ideally, all the existing private peering fabrics should fit into the speermint umbrella. * scales to wide adoption, both for SIP URIs / domains as well as peering operators. Nothing in the protocol should preclude that it is used e.g. to get VoIP-enabled PBX systems to peer with each other. (Whether a carrier wants to peer with a PBX is his choice. The protocol shouldn't dictate a peering policy. The contrary: the protocol must support all possible peering policies.) * gives BCPs on how to do the nitty-gritty SIP details (caller-ID, privacy, ...) /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 30 17:43:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlC01-0002r1-QW; Tue, 30 May 2006 17:43:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlC01-0002qw-EX for speermint@ietf.org; Tue, 30 May 2006 17:43:37 -0400 Received: from qfe1.f10207-20.atlanta2.level3.net ([67.72.93.25] helo=f10207-20.adc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlC01-0007yp-0v for speermint@ietf.org; Tue, 30 May 2006 17:43:37 -0400 Received: from machine77.Level3.com (qfe0.f4ff49-08.idc1.oss.level3.com [10.1.156.103]) by f10207-20.adc1.level3.com (8.12.10/8.12.10) with ESMTP id k4ULh36r009271; Tue, 30 May 2006 21:43:09 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id ADE5778B44F; Tue, 30 May 2006 21:43:02 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner3.l3.com (Postfix) with SMTP id 6C43178B46A; Tue, 30 May 2006 21:43:02 +0000 (GMT) Received: from idc1exc0006.corp.global.level3.com ([10.1.9.17]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 May 2006 15:43:01 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 30 May 2006 15:43:00 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaEEdBAV/nhiie0SOG4l7wbr22a4gADATtAAAFX9mAAAJ5/MAABDMqQAAGZpmA= From: "Malas, Daryl" To: "Brian Rosen" , "Pfautz, Penn L, GBLAM" , "Otmar Lendl" , X-OriginalArrivalTime: 30 May 2006 21:43:01.0886 (UTC) FILETIME=[067F11E0:01C68432] X-Spam-Score: 0.1 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I was thinking in terms of Contradiction 2 (if I'm reading your list correctly)...B won't tell A about it's routes to C and D, because B has negotiated a "private" relationship with A. In this case, A can only route to B (and D via it's other "private" relationship). In this case, I am not describing a transit scenario with B. B simply has multiple peering relationships with varying types of peering partners (public or open vs. private). Now please don't confuse the internet as implying a public peering relationship, although that is what I intended for this example. The internet is simply a layer 3 mechanism, and a private peering relationship could exist via that path as well. Peering can and should be architected to work in a transit scenario as well, as you began to describe below. A peers with B, because it knows B is peered with many federations or domains. In this case, B is acting as a transit or termination peering hub to multiple spokes (if I can use that analogy liberally) -- B may also have domains associated with it. Also, A could still maintain a private peering relationship with D, to create multiple layer 5 path choices for getting to D. For example, D may be peered with a DS-3 with high levels of quality (e.g. diffserv, ToS, etc.), while the peering relationship to B may be an OC-12 without quality guarantees. A's primary choice to D is via it's private peering relationship to D, and a secondary choice is through B. This is getting fairly complex, but all of these are good to hash out in the architecture document...otherwise, the industry will run with crazy one-offs in every different direction causing incompatibilities on several levels. --Daryl -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, May 30, 2006 3:03 PM To: 'Pfautz, Penn L, GBLAM'; Malas, Daryl; 'Otmar Lendl'; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Perhaps we are misinterpreting the figure. I am interpreting C as accepting calls over the Internet from any domain (that is, not limited to specific peers). I'm not just thinking that the peering fabric is the Internet; of course any connection between peers can traverse the Internet. I assume A knows it wants a route to C. ENUM is out of scope. The Route Advertisement is what domains B tells A it can get to, so that A knows B can get to C. Contradiction 1 is that if C is known to accept connections from any domain, then B is not adding value. It can't be a secret only known to B that C accepts any connections. Contradiction 2 is that B can't tell A that it can reach all possible C's. A specific C, maybe, but then you are back to Contradiction 1. Let's be more concrete. Suppose there is an enterprise with a SIP PBX. Suppose it starts out by purchasing VoIP termination services from a carrier and sends all its traffic there, and to start, only accepts traffic from its carrier. Now, suppose that at some point the enterprise gets comfortable and starts allowing traffic from the Internet direct to its PBX. Suppose, just to get it off the table, that there is public ENUM, so number services are not an issue. This enterprise is now a "C". How does B tell A that it can get to C? How does it know that? Generally, C freely "advertises" its "route" by simply putting an SRV record in its public DNS. What is the way A "seeks a route to C" by any mechanism short of just trying DNS. What I'm getting at is that B can't make a definitive list of all the C's out there, and there is no wildcard that works. =20 Brian -----Original Message----- From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com]=20 Sent: Tuesday, May 30, 2006 4:20 PM To: Brian Rosen; Malas, Daryl; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Sorry, sent too soon... This is the kind of thing that makes we wonder why anyone wants to look at this in terms of route advertisement where A doesn't know the destination is C and just looks at what B says it can reach. I can imagine that A knows the ultimate destination is C and then seeks a route to C, which would eliminate the contradictions Brian raises. =20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, May 30, 2006 4:02 PM To: 'Malas, Daryl'; 'Otmar Lendl'; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture I am absolutely certain that these kinds of arrangements will be seen "in the wild". Two thoughts strike me: 1) If Domain A is paying Domain B a lot for this kind of service, it may need a software update so it can do it itself 2) The route advertisement from B towards A gets REALLY tricky. The reason is that there is no convenient way to express it. It's not "*" (I can get you to any domain). It's "I can get you to any domain that accepts connections from the Internet". It's the terminating network that decides if it will allow traffic from some other domain, and "Domain B" below, doesn't know what the rules for Domain C are. Brian -----Original Message----- From: Malas, Daryl [mailto:Daryl.Malas@Level3.com]=20 Sent: Tuesday, May 30, 2006 3:45 PM To: Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture In addition to your comments below, I think peering will likely occur in one of the following methods or all of them (this includes the capabilities described in the Peering Architecture Draft: =20 +---------+ | | +--------+ +--------+ +------------+ /|Domain C |=20 | | | | / \ / | | |Domain A| Private |Domain B| Public | Internet |/ +---------+ | |=3D=3D=3D=3D=3D=3D=3D=3D=3D| = |=3D=3D=3D=3D=3D=3D=3D=3D=3D| |\ | | Peer | | Peer \ / \ +---------+ +--------+ +--------+ +------------+ \| | || |Domain D |=09 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D| |=09 Private Peer +---------+ As far as PBX interconnect goes... I don't think SPEERMINT should design a tie-line replacement architecture. IMO, it is out of scope. I know this becomes somewhat blurry, as more SIP PBX's are a conglomeration of multiple SIP capabilities (e.g. UA, UAS, Proxy, etc.), some of which are described in the architecture. However, the SIP Forum is already addressing many of those concerns in SIP Forum drafts such as: sf-draft-twg-IP_PBX_SP_Interop-sibley-v5.pdf. My two cents... =09 --Daryl M. -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at]=20 Sent: Tuesday, May 30, 2006 11:51 AM To: speermint@ietf.org Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture On 2006/05/30 19:05, "Livingood, Jason" wrote: > > I believe this discussion has gone over the edge. > >=20 > > The reason SPEERMINT exists is that CARRIERS want to peer. >=20 > Perhaps a fair assessment, but I suspect we all would like it to > progress beyond that. =20 > =20 > > Email is an inappropriate metaphor for carrier peering. >=20 > Perhaps but I don't think we can conclude that as yet. There are most > definitely differences though. I see no reason not to try to take some > of the simplicity and ubiquity of that model and trying to apply it to a > new application where it makes sense. My take is that we need a system that * allows selective peering. If we require that everybody can talk directly to everybody else, we don't get carrier opt-in. * supports branching off into private interconnects. Ideally, all the existing private peering fabrics should fit into the speermint umbrella. * scales to wide adoption, both for SIP URIs / domains as well as peering operators. Nothing in the protocol should preclude that it is used e.g. to get VoIP-enabled PBX systems to peer with each other. (Whether a carrier wants to peer with a PBX is his choice.=20 The protocol shouldn't dictate a peering policy. The contrary: the protocol must support all possible peering policies.) * gives BCPs on how to do the nitty-gritty SIP details (caller-ID, privacy, ...) /ol --=20 < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 30 17:54:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlCA7-0006Hg-BF; Tue, 30 May 2006 17:54:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlCA5-0006Hb-Ib for speermint@ietf.org; Tue, 30 May 2006 17:54:01 -0400 Received: from qfe1.f10207-20.atlanta2.level3.net ([67.72.93.25] helo=f10207-20.adc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlCA5-0001eF-4D for speermint@ietf.org; Tue, 30 May 2006 17:54:01 -0400 Received: from machine77.Level3.com (qfe0.f4ff49-08.idc1.oss.level3.com [10.1.156.103]) by f10207-20.adc1.level3.com (8.12.10/8.12.10) with ESMTP id k4ULre6r012624; Tue, 30 May 2006 21:53:40 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id B67D278B453; Tue, 30 May 2006 21:53:39 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner3.l3.com (Postfix) with SMTP id 84CD378B43E; Tue, 30 May 2006 21:53:39 +0000 (GMT) Received: from idc1exc0006.corp.global.level3.com ([10.1.9.17]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 May 2006 15:53:39 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 30 May 2006 15:53:38 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaEEdBAV/nhiie0SOG4l7wbr22a4gADATtAAAFX9mAAAJ5/MAABDMqQAAGZpmAAALEUgA== From: "Malas, Daryl" To: "Brian Rosen" , "Pfautz, Penn L, GBLAM" , "Otmar Lendl" , X-OriginalArrivalTime: 30 May 2006 21:53:39.0410 (UTC) FILETIME=[827D8320:01C68433] X-Spam-Score: 0.1 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org After reading my own email, I think I have implied 3 different peering policies (not flows): 1. Private - It is a 1:1 relationship. I peer with you and you with me...no other options...no other routes, etc. 2. Public - I'll peer with anyone 1:*, as long as you meet the policy criteria I have specified. 3. Transit - I am peered to many, but will only allow you to peer with some or all of my peers based on my peers and my policies. Any thoughts?? --Daryl M. -----Original Message----- From: Malas, Daryl=20 Sent: Tuesday, May 30, 2006 3:43 PM To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture I was thinking in terms of Contradiction 2 (if I'm reading your list correctly)...B won't tell A about it's routes to C and D, because B has negotiated a "private" relationship with A. In this case, A can only route to B (and D via it's other "private" relationship). In this case, I am not describing a transit scenario with B. B simply has multiple peering relationships with varying types of peering partners (public or open vs. private). Now please don't confuse the internet as implying a public peering relationship, although that is what I intended for this example. The internet is simply a layer 3 mechanism, and a private peering relationship could exist via that path as well. Peering can and should be architected to work in a transit scenario as well, as you began to describe below. A peers with B, because it knows B is peered with many federations or domains. In this case, B is acting as a transit or termination peering hub to multiple spokes (if I can use that analogy liberally) -- B may also have domains associated with it. Also, A could still maintain a private peering relationship with D, to create multiple layer 5 path choices for getting to D. For example, D may be peered with a DS-3 with high levels of quality (e.g. diffserv, ToS, etc.), while the peering relationship to B may be an OC-12 without quality guarantees. A's primary choice to D is via it's private peering relationship to D, and a secondary choice is through B. This is getting fairly complex, but all of these are good to hash out in the architecture document...otherwise, the industry will run with crazy one-offs in every different direction causing incompatibilities on several levels. --Daryl -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, May 30, 2006 3:03 PM To: 'Pfautz, Penn L, GBLAM'; Malas, Daryl; 'Otmar Lendl'; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Perhaps we are misinterpreting the figure. I am interpreting C as accepting calls over the Internet from any domain (that is, not limited to specific peers). I'm not just thinking that the peering fabric is the Internet; of course any connection between peers can traverse the Internet. I assume A knows it wants a route to C. ENUM is out of scope. The Route Advertisement is what domains B tells A it can get to, so that A knows B can get to C. Contradiction 1 is that if C is known to accept connections from any domain, then B is not adding value. It can't be a secret only known to B that C accepts any connections. Contradiction 2 is that B can't tell A that it can reach all possible C's. A specific C, maybe, but then you are back to Contradiction 1. Let's be more concrete. Suppose there is an enterprise with a SIP PBX. Suppose it starts out by purchasing VoIP termination services from a carrier and sends all its traffic there, and to start, only accepts traffic from its carrier. Now, suppose that at some point the enterprise gets comfortable and starts allowing traffic from the Internet direct to its PBX. Suppose, just to get it off the table, that there is public ENUM, so number services are not an issue. This enterprise is now a "C". How does B tell A that it can get to C? How does it know that? Generally, C freely "advertises" its "route" by simply putting an SRV record in its public DNS. What is the way A "seeks a route to C" by any mechanism short of just trying DNS. What I'm getting at is that B can't make a definitive list of all the C's out there, and there is no wildcard that works. =20 Brian -----Original Message----- From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com]=20 Sent: Tuesday, May 30, 2006 4:20 PM To: Brian Rosen; Malas, Daryl; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Sorry, sent too soon... This is the kind of thing that makes we wonder why anyone wants to look at this in terms of route advertisement where A doesn't know the destination is C and just looks at what B says it can reach. I can imagine that A knows the ultimate destination is C and then seeks a route to C, which would eliminate the contradictions Brian raises. =20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, May 30, 2006 4:02 PM To: 'Malas, Daryl'; 'Otmar Lendl'; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture I am absolutely certain that these kinds of arrangements will be seen "in the wild". Two thoughts strike me: 1) If Domain A is paying Domain B a lot for this kind of service, it may need a software update so it can do it itself 2) The route advertisement from B towards A gets REALLY tricky. The reason is that there is no convenient way to express it. It's not "*" (I can get you to any domain). It's "I can get you to any domain that accepts connections from the Internet". It's the terminating network that decides if it will allow traffic from some other domain, and "Domain B" below, doesn't know what the rules for Domain C are. Brian -----Original Message----- From: Malas, Daryl [mailto:Daryl.Malas@Level3.com]=20 Sent: Tuesday, May 30, 2006 3:45 PM To: Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture In addition to your comments below, I think peering will likely occur in one of the following methods or all of them (this includes the capabilities described in the Peering Architecture Draft: =20 +---------+ | | +--------+ +--------+ +------------+ /|Domain C |=20 | | | | / \ / | | |Domain A| Private |Domain B| Public | Internet |/ +---------+ | |=3D=3D=3D=3D=3D=3D=3D=3D=3D| = |=3D=3D=3D=3D=3D=3D=3D=3D=3D| |\ | | Peer | | Peer \ / \ +---------+ +--------+ +--------+ +------------+ \| | || |Domain D |=09 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D| |=09 Private Peer +---------+ As far as PBX interconnect goes... I don't think SPEERMINT should design a tie-line replacement architecture. IMO, it is out of scope. I know this becomes somewhat blurry, as more SIP PBX's are a conglomeration of multiple SIP capabilities (e.g. UA, UAS, Proxy, etc.), some of which are described in the architecture. However, the SIP Forum is already addressing many of those concerns in SIP Forum drafts such as: sf-draft-twg-IP_PBX_SP_Interop-sibley-v5.pdf. My two cents... =09 --Daryl M. -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at]=20 Sent: Tuesday, May 30, 2006 11:51 AM To: speermint@ietf.org Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture On 2006/05/30 19:05, "Livingood, Jason" wrote: > > I believe this discussion has gone over the edge. > >=20 > > The reason SPEERMINT exists is that CARRIERS want to peer. >=20 > Perhaps a fair assessment, but I suspect we all would like it to > progress beyond that. =20 > =20 > > Email is an inappropriate metaphor for carrier peering. >=20 > Perhaps but I don't think we can conclude that as yet. There are most > definitely differences though. I see no reason not to try to take some > of the simplicity and ubiquity of that model and trying to apply it to a > new application where it makes sense. My take is that we need a system that * allows selective peering. If we require that everybody can talk directly to everybody else, we don't get carrier opt-in. * supports branching off into private interconnects. Ideally, all the existing private peering fabrics should fit into the speermint umbrella. * scales to wide adoption, both for SIP URIs / domains as well as peering operators. Nothing in the protocol should preclude that it is used e.g. to get VoIP-enabled PBX systems to peer with each other. (Whether a carrier wants to peer with a PBX is his choice.=20 The protocol shouldn't dictate a peering policy. The contrary: the protocol must support all possible peering policies.) * gives BCPs on how to do the nitty-gritty SIP details (caller-ID, privacy, ...) /ol --=20 < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 30 18:09:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlCOI-0002rZ-Ik; Tue, 30 May 2006 18:08:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlCOH-0002rU-4d for speermint@ietf.org; Tue, 30 May 2006 18:08:41 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlCOG-00038V-J2 for speermint@ietf.org; Tue, 30 May 2006 18:08:41 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FlCNu-0001RA-3E; Tue, 30 May 2006 17:08:19 -0500 From: "Brian Rosen" To: "'Malas, Daryl'" , "'Pfautz, Penn L, GBLAM'" , "'Otmar Lendl'" , Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 30 May 2006 18:08:20 -0400 Message-ID: <04ef01c68435$92f80a20$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaEEdBAV/nhiie0SOG4l7wbr22a4gADATtAAAFX9mAAAJ5/MAABDMqQAAGZpmAAARBe8A== X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I misinterpreted your diagram. I thought you were talking about public "peering" on the Internet with B as a transit network. Agree that any link between peers can be an Internet link. I think it's not helpful to show them in diagrams like this; it just confuses things. Nothing is different except the packet path, and we don't care about that in this WG. Agree that if you have route advertisements, you can have multiple paths to the same termination and you need a "cost" metric to choose. Standard stuff, and I hope we aren't planning to go overboard on the "cost" metric. Transit is independent from multiple paths. I could easily see B being part of multiple peering federations, where, say D is in more than one of them also, so B has at least two paths to D with no transit networks. Transit is path aggregation (A can get to B, B can get to D, so A can get to both B and D via the same path). Brian -----Original Message----- From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] Sent: Tuesday, May 30, 2006 5:43 PM To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture I was thinking in terms of Contradiction 2 (if I'm reading your list correctly)...B won't tell A about it's routes to C and D, because B has negotiated a "private" relationship with A. In this case, A can only route to B (and D via it's other "private" relationship). In this case, I am not describing a transit scenario with B. B simply has multiple peering relationships with varying types of peering partners (public or open vs. private). Now please don't confuse the internet as implying a public peering relationship, although that is what I intended for this example. The internet is simply a layer 3 mechanism, and a private peering relationship could exist via that path as well. Peering can and should be architected to work in a transit scenario as well, as you began to describe below. A peers with B, because it knows B is peered with many federations or domains. In this case, B is acting as a transit or termination peering hub to multiple spokes (if I can use that analogy liberally) -- B may also have domains associated with it. Also, A could still maintain a private peering relationship with D, to create multiple layer 5 path choices for getting to D. For example, D may be peered with a DS-3 with high levels of quality (e.g. diffserv, ToS, etc.), while the peering relationship to B may be an OC-12 without quality guarantees. A's primary choice to D is via it's private peering relationship to D, and a secondary choice is through B. This is getting fairly complex, but all of these are good to hash out in the architecture document...otherwise, the industry will run with crazy one-offs in every different direction causing incompatibilities on several levels. --Daryl -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, May 30, 2006 3:03 PM To: 'Pfautz, Penn L, GBLAM'; Malas, Daryl; 'Otmar Lendl'; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Perhaps we are misinterpreting the figure. I am interpreting C as accepting calls over the Internet from any domain (that is, not limited to specific peers). I'm not just thinking that the peering fabric is the Internet; of course any connection between peers can traverse the Internet. I assume A knows it wants a route to C. ENUM is out of scope. The Route Advertisement is what domains B tells A it can get to, so that A knows B can get to C. Contradiction 1 is that if C is known to accept connections from any domain, then B is not adding value. It can't be a secret only known to B that C accepts any connections. Contradiction 2 is that B can't tell A that it can reach all possible C's. A specific C, maybe, but then you are back to Contradiction 1. Let's be more concrete. Suppose there is an enterprise with a SIP PBX. Suppose it starts out by purchasing VoIP termination services from a carrier and sends all its traffic there, and to start, only accepts traffic from its carrier. Now, suppose that at some point the enterprise gets comfortable and starts allowing traffic from the Internet direct to its PBX. Suppose, just to get it off the table, that there is public ENUM, so number services are not an issue. This enterprise is now a "C". How does B tell A that it can get to C? How does it know that? Generally, C freely "advertises" its "route" by simply putting an SRV record in its public DNS. What is the way A "seeks a route to C" by any mechanism short of just trying DNS. What I'm getting at is that B can't make a definitive list of all the C's out there, and there is no wildcard that works. Brian -----Original Message----- From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] Sent: Tuesday, May 30, 2006 4:20 PM To: Brian Rosen; Malas, Daryl; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Sorry, sent too soon... This is the kind of thing that makes we wonder why anyone wants to look at this in terms of route advertisement where A doesn't know the destination is C and just looks at what B says it can reach. I can imagine that A knows the ultimate destination is C and then seeks a route to C, which would eliminate the contradictions Brian raises. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, May 30, 2006 4:02 PM To: 'Malas, Daryl'; 'Otmar Lendl'; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture I am absolutely certain that these kinds of arrangements will be seen "in the wild". Two thoughts strike me: 1) If Domain A is paying Domain B a lot for this kind of service, it may need a software update so it can do it itself 2) The route advertisement from B towards A gets REALLY tricky. The reason is that there is no convenient way to express it. It's not "*" (I can get you to any domain). It's "I can get you to any domain that accepts connections from the Internet". It's the terminating network that decides if it will allow traffic from some other domain, and "Domain B" below, doesn't know what the rules for Domain C are. Brian -----Original Message----- From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] Sent: Tuesday, May 30, 2006 3:45 PM To: Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture In addition to your comments below, I think peering will likely occur in one of the following methods or all of them (this includes the capabilities described in the Peering Architecture Draft: +---------+ | | +--------+ +--------+ +------------+ /|Domain C | | | | | / \ / | | |Domain A| Private |Domain B| Public | Internet |/ +---------+ | |=========| |=========| |\ | | Peer | | Peer \ / \ +---------+ +--------+ +--------+ +------------+ \| | || |Domain D | =======================================================| | Private Peer +---------+ As far as PBX interconnect goes... I don't think SPEERMINT should design a tie-line replacement architecture. IMO, it is out of scope. I know this becomes somewhat blurry, as more SIP PBX's are a conglomeration of multiple SIP capabilities (e.g. UA, UAS, Proxy, etc.), some of which are described in the architecture. However, the SIP Forum is already addressing many of those concerns in SIP Forum drafts such as: sf-draft-twg-IP_PBX_SP_Interop-sibley-v5.pdf. My two cents... --Daryl M. -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at] Sent: Tuesday, May 30, 2006 11:51 AM To: speermint@ietf.org Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture On 2006/05/30 19:05, "Livingood, Jason" wrote: > > I believe this discussion has gone over the edge. > > > > The reason SPEERMINT exists is that CARRIERS want to peer. > > Perhaps a fair assessment, but I suspect we all would like it to > progress beyond that. > > > Email is an inappropriate metaphor for carrier peering. > > Perhaps but I don't think we can conclude that as yet. There are most > definitely differences though. I see no reason not to try to take some > of the simplicity and ubiquity of that model and trying to apply it to a > new application where it makes sense. My take is that we need a system that * allows selective peering. If we require that everybody can talk directly to everybody else, we don't get carrier opt-in. * supports branching off into private interconnects. Ideally, all the existing private peering fabrics should fit into the speermint umbrella. * scales to wide adoption, both for SIP URIs / domains as well as peering operators. Nothing in the protocol should preclude that it is used e.g. to get VoIP-enabled PBX systems to peer with each other. (Whether a carrier wants to peer with a PBX is his choice. The protocol shouldn't dictate a peering policy. The contrary: the protocol must support all possible peering policies.) * gives BCPs on how to do the nitty-gritty SIP details (caller-ID, privacy, ...) /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 30 18:10:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlCPw-0003Li-61; Tue, 30 May 2006 18:10:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlCPu-0003FB-Ah for speermint@ietf.org; Tue, 30 May 2006 18:10:22 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlCPs-0003BG-Oj for speermint@ietf.org; Tue, 30 May 2006 18:10:22 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FlCPX-0001Uy-Je; Tue, 30 May 2006 17:10:00 -0500 From: "Brian Rosen" To: "'Malas, Daryl'" , "'Pfautz, Penn L, GBLAM'" , "'Otmar Lendl'" , Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 30 May 2006 18:10:03 -0400 Message-ID: <04f001c68435$cf778ed0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaEEdBAV/nhiie0SOG4l7wbr22a4gADATtAAAFX9mAAAJ5/MAABDMqQAAGZpmAAALEUgAAAooFw X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I don't like your definition of "transit". Transit means "I am peered to others, and they will permit me to let you get to them through me". Brian -----Original Message----- From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] Sent: Tuesday, May 30, 2006 5:54 PM To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture After reading my own email, I think I have implied 3 different peering policies (not flows): 1. Private - It is a 1:1 relationship. I peer with you and you with me...no other options...no other routes, etc. 2. Public - I'll peer with anyone 1:*, as long as you meet the policy criteria I have specified. 3. Transit - I am peered to many, but will only allow you to peer with some or all of my peers based on my peers and my policies. Any thoughts?? --Daryl M. -----Original Message----- From: Malas, Daryl Sent: Tuesday, May 30, 2006 3:43 PM To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture I was thinking in terms of Contradiction 2 (if I'm reading your list correctly)...B won't tell A about it's routes to C and D, because B has negotiated a "private" relationship with A. In this case, A can only route to B (and D via it's other "private" relationship). In this case, I am not describing a transit scenario with B. B simply has multiple peering relationships with varying types of peering partners (public or open vs. private). Now please don't confuse the internet as implying a public peering relationship, although that is what I intended for this example. The internet is simply a layer 3 mechanism, and a private peering relationship could exist via that path as well. Peering can and should be architected to work in a transit scenario as well, as you began to describe below. A peers with B, because it knows B is peered with many federations or domains. In this case, B is acting as a transit or termination peering hub to multiple spokes (if I can use that analogy liberally) -- B may also have domains associated with it. Also, A could still maintain a private peering relationship with D, to create multiple layer 5 path choices for getting to D. For example, D may be peered with a DS-3 with high levels of quality (e.g. diffserv, ToS, etc.), while the peering relationship to B may be an OC-12 without quality guarantees. A's primary choice to D is via it's private peering relationship to D, and a secondary choice is through B. This is getting fairly complex, but all of these are good to hash out in the architecture document...otherwise, the industry will run with crazy one-offs in every different direction causing incompatibilities on several levels. --Daryl -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, May 30, 2006 3:03 PM To: 'Pfautz, Penn L, GBLAM'; Malas, Daryl; 'Otmar Lendl'; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Perhaps we are misinterpreting the figure. I am interpreting C as accepting calls over the Internet from any domain (that is, not limited to specific peers). I'm not just thinking that the peering fabric is the Internet; of course any connection between peers can traverse the Internet. I assume A knows it wants a route to C. ENUM is out of scope. The Route Advertisement is what domains B tells A it can get to, so that A knows B can get to C. Contradiction 1 is that if C is known to accept connections from any domain, then B is not adding value. It can't be a secret only known to B that C accepts any connections. Contradiction 2 is that B can't tell A that it can reach all possible C's. A specific C, maybe, but then you are back to Contradiction 1. Let's be more concrete. Suppose there is an enterprise with a SIP PBX. Suppose it starts out by purchasing VoIP termination services from a carrier and sends all its traffic there, and to start, only accepts traffic from its carrier. Now, suppose that at some point the enterprise gets comfortable and starts allowing traffic from the Internet direct to its PBX. Suppose, just to get it off the table, that there is public ENUM, so number services are not an issue. This enterprise is now a "C". How does B tell A that it can get to C? How does it know that? Generally, C freely "advertises" its "route" by simply putting an SRV record in its public DNS. What is the way A "seeks a route to C" by any mechanism short of just trying DNS. What I'm getting at is that B can't make a definitive list of all the C's out there, and there is no wildcard that works. Brian -----Original Message----- From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] Sent: Tuesday, May 30, 2006 4:20 PM To: Brian Rosen; Malas, Daryl; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Sorry, sent too soon... This is the kind of thing that makes we wonder why anyone wants to look at this in terms of route advertisement where A doesn't know the destination is C and just looks at what B says it can reach. I can imagine that A knows the ultimate destination is C and then seeks a route to C, which would eliminate the contradictions Brian raises. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, May 30, 2006 4:02 PM To: 'Malas, Daryl'; 'Otmar Lendl'; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture I am absolutely certain that these kinds of arrangements will be seen "in the wild". Two thoughts strike me: 1) If Domain A is paying Domain B a lot for this kind of service, it may need a software update so it can do it itself 2) The route advertisement from B towards A gets REALLY tricky. The reason is that there is no convenient way to express it. It's not "*" (I can get you to any domain). It's "I can get you to any domain that accepts connections from the Internet". It's the terminating network that decides if it will allow traffic from some other domain, and "Domain B" below, doesn't know what the rules for Domain C are. Brian -----Original Message----- From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] Sent: Tuesday, May 30, 2006 3:45 PM To: Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture In addition to your comments below, I think peering will likely occur in one of the following methods or all of them (this includes the capabilities described in the Peering Architecture Draft: +---------+ | | +--------+ +--------+ +------------+ /|Domain C | | | | | / \ / | | |Domain A| Private |Domain B| Public | Internet |/ +---------+ | |=========| |=========| |\ | | Peer | | Peer \ / \ +---------+ +--------+ +--------+ +------------+ \| | || |Domain D | =======================================================| | Private Peer +---------+ As far as PBX interconnect goes... I don't think SPEERMINT should design a tie-line replacement architecture. IMO, it is out of scope. I know this becomes somewhat blurry, as more SIP PBX's are a conglomeration of multiple SIP capabilities (e.g. UA, UAS, Proxy, etc.), some of which are described in the architecture. However, the SIP Forum is already addressing many of those concerns in SIP Forum drafts such as: sf-draft-twg-IP_PBX_SP_Interop-sibley-v5.pdf. My two cents... --Daryl M. -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at] Sent: Tuesday, May 30, 2006 11:51 AM To: speermint@ietf.org Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture On 2006/05/30 19:05, "Livingood, Jason" wrote: > > I believe this discussion has gone over the edge. > > > > The reason SPEERMINT exists is that CARRIERS want to peer. > > Perhaps a fair assessment, but I suspect we all would like it to > progress beyond that. > > > Email is an inappropriate metaphor for carrier peering. > > Perhaps but I don't think we can conclude that as yet. There are most > definitely differences though. I see no reason not to try to take some > of the simplicity and ubiquity of that model and trying to apply it to a > new application where it makes sense. My take is that we need a system that * allows selective peering. If we require that everybody can talk directly to everybody else, we don't get carrier opt-in. * supports branching off into private interconnects. Ideally, all the existing private peering fabrics should fit into the speermint umbrella. * scales to wide adoption, both for SIP URIs / domains as well as peering operators. Nothing in the protocol should preclude that it is used e.g. to get VoIP-enabled PBX systems to peer with each other. (Whether a carrier wants to peer with a PBX is his choice. The protocol shouldn't dictate a peering policy. The contrary: the protocol must support all possible peering policies.) * gives BCPs on how to do the nitty-gritty SIP details (caller-ID, privacy, ...) /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 30 18:18:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlCXg-000545-7Q; Tue, 30 May 2006 18:18:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlCXf-000540-DP for speermint@ietf.org; Tue, 30 May 2006 18:18:23 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlCXe-0003M0-Sm for speermint@ietf.org; Tue, 30 May 2006 18:18:23 -0400 Received: from machine77.Level3.com (qfe0.f10212-07.adc1.oss.level3.com [10.2.1.102]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k4UMIEaK015016; Tue, 30 May 2006 22:18:14 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id 09BD5124822; Tue, 30 May 2006 22:18:14 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner5.level3.com (Postfix) with SMTP id A1EBF124815; Tue, 30 May 2006 22:18:13 +0000 (GMT) Received: from idc1exc0006.corp.global.level3.com ([10.1.9.17]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 May 2006 16:18:13 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 30 May 2006 16:18:12 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaEEdBAV/nhiie0SOG4l7wbr22a4gADATtAAAFX9mAAAJ5/MAABDMqQAAGZpmAAALEUgAAAooFwAAAiHGA= From: "Malas, Daryl" To: "Brian Rosen" , "Pfautz, Penn L, GBLAM" , "Otmar Lendl" , X-OriginalArrivalTime: 30 May 2006 22:18:13.0437 (UTC) FILETIME=[F1142ED0:01C68436] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org So, I'm trying to differentiate traditional PSTN transit from SPEERMINT transit. I think the features/extensions of SIP provide a more intelligent capability of transit than traditional TDM/SS7 interconnections. I took your definition (described below) to a "next step up" approach, where my peers and/or my policies may permit transit to only some or all of my peers. ...I suppose, your definition does work; because, technically my other peers do not exist to you if I don't allow you to transit to them due to my policies or theirs. Sorry, it's a little confusing, but I hope it makes sense. I may be breaking the traditional term of transit, but I think it fits the capability the closest. If you can come up with a better "summarizing" term, I'm listening. ;-) --Daryl M. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, May 30, 2006 4:10 PM To: Malas, Daryl; 'Pfautz, Penn L, GBLAM'; 'Otmar Lendl'; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture I don't like your definition of "transit". Transit means "I am peered to others, and they will permit me to let you get to them through me". =20 Brian -----Original Message----- From: Malas, Daryl [mailto:Daryl.Malas@Level3.com]=20 Sent: Tuesday, May 30, 2006 5:54 PM To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture After reading my own email, I think I have implied 3 different peering policies (not flows): 1. Private - It is a 1:1 relationship. I peer with you and you with me...no other options...no other routes, etc. 2. Public - I'll peer with anyone 1:*, as long as you meet the policy criteria I have specified. 3. Transit - I am peered to many, but will only allow you to peer with some or all of my peers based on my peers and my policies. Any thoughts?? --Daryl M. -----Original Message----- From: Malas, Daryl=20 Sent: Tuesday, May 30, 2006 3:43 PM To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture I was thinking in terms of Contradiction 2 (if I'm reading your list correctly)...B won't tell A about it's routes to C and D, because B has negotiated a "private" relationship with A. In this case, A can only route to B (and D via it's other "private" relationship). In this case, I am not describing a transit scenario with B. B simply has multiple peering relationships with varying types of peering partners (public or open vs. private). Now please don't confuse the internet as implying a public peering relationship, although that is what I intended for this example. The internet is simply a layer 3 mechanism, and a private peering relationship could exist via that path as well. Peering can and should be architected to work in a transit scenario as well, as you began to describe below. A peers with B, because it knows B is peered with many federations or domains. In this case, B is acting as a transit or termination peering hub to multiple spokes (if I can use that analogy liberally) -- B may also have domains associated with it. Also, A could still maintain a private peering relationship with D, to create multiple layer 5 path choices for getting to D. For example, D may be peered with a DS-3 with high levels of quality (e.g. diffserv, ToS, etc.), while the peering relationship to B may be an OC-12 without quality guarantees. A's primary choice to D is via it's private peering relationship to D, and a secondary choice is through B. This is getting fairly complex, but all of these are good to hash out in the architecture document...otherwise, the industry will run with crazy one-offs in every different direction causing incompatibilities on several levels. --Daryl -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, May 30, 2006 3:03 PM To: 'Pfautz, Penn L, GBLAM'; Malas, Daryl; 'Otmar Lendl'; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Perhaps we are misinterpreting the figure. I am interpreting C as accepting calls over the Internet from any domain (that is, not limited to specific peers). I'm not just thinking that the peering fabric is the Internet; of course any connection between peers can traverse the Internet. I assume A knows it wants a route to C. ENUM is out of scope. The Route Advertisement is what domains B tells A it can get to, so that A knows B can get to C. Contradiction 1 is that if C is known to accept connections from any domain, then B is not adding value. It can't be a secret only known to B that C accepts any connections. Contradiction 2 is that B can't tell A that it can reach all possible C's. A specific C, maybe, but then you are back to Contradiction 1. Let's be more concrete. Suppose there is an enterprise with a SIP PBX. Suppose it starts out by purchasing VoIP termination services from a carrier and sends all its traffic there, and to start, only accepts traffic from its carrier. Now, suppose that at some point the enterprise gets comfortable and starts allowing traffic from the Internet direct to its PBX. Suppose, just to get it off the table, that there is public ENUM, so number services are not an issue. This enterprise is now a "C". How does B tell A that it can get to C? How does it know that? Generally, C freely "advertises" its "route" by simply putting an SRV record in its public DNS. What is the way A "seeks a route to C" by any mechanism short of just trying DNS. What I'm getting at is that B can't make a definitive list of all the C's out there, and there is no wildcard that works. =20 Brian -----Original Message----- From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com]=20 Sent: Tuesday, May 30, 2006 4:20 PM To: Brian Rosen; Malas, Daryl; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Sorry, sent too soon... This is the kind of thing that makes we wonder why anyone wants to look at this in terms of route advertisement where A doesn't know the destination is C and just looks at what B says it can reach. I can imagine that A knows the ultimate destination is C and then seeks a route to C, which would eliminate the contradictions Brian raises. =20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, May 30, 2006 4:02 PM To: 'Malas, Daryl'; 'Otmar Lendl'; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture I am absolutely certain that these kinds of arrangements will be seen "in the wild". Two thoughts strike me: 1) If Domain A is paying Domain B a lot for this kind of service, it may need a software update so it can do it itself 2) The route advertisement from B towards A gets REALLY tricky. The reason is that there is no convenient way to express it. It's not "*" (I can get you to any domain). It's "I can get you to any domain that accepts connections from the Internet". It's the terminating network that decides if it will allow traffic from some other domain, and "Domain B" below, doesn't know what the rules for Domain C are. Brian -----Original Message----- From: Malas, Daryl [mailto:Daryl.Malas@Level3.com]=20 Sent: Tuesday, May 30, 2006 3:45 PM To: Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture In addition to your comments below, I think peering will likely occur in one of the following methods or all of them (this includes the capabilities described in the Peering Architecture Draft: =20 +---------+ | | +--------+ +--------+ +------------+ /|Domain C |=20 | | | | / \ / | | |Domain A| Private |Domain B| Public | Internet |/ +---------+ | |=3D=3D=3D=3D=3D=3D=3D=3D=3D| = |=3D=3D=3D=3D=3D=3D=3D=3D=3D| |\ | | Peer | | Peer \ / \ +---------+ +--------+ +--------+ +------------+ \| | || |Domain D |=09 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D| |=09 Private Peer +---------+ As far as PBX interconnect goes... I don't think SPEERMINT should design a tie-line replacement architecture. IMO, it is out of scope. I know this becomes somewhat blurry, as more SIP PBX's are a conglomeration of multiple SIP capabilities (e.g. UA, UAS, Proxy, etc.), some of which are described in the architecture. However, the SIP Forum is already addressing many of those concerns in SIP Forum drafts such as: sf-draft-twg-IP_PBX_SP_Interop-sibley-v5.pdf. My two cents... =09 --Daryl M. -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at]=20 Sent: Tuesday, May 30, 2006 11:51 AM To: speermint@ietf.org Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture On 2006/05/30 19:05, "Livingood, Jason" wrote: > > I believe this discussion has gone over the edge. > >=20 > > The reason SPEERMINT exists is that CARRIERS want to peer. >=20 > Perhaps a fair assessment, but I suspect we all would like it to > progress beyond that. =20 > =20 > > Email is an inappropriate metaphor for carrier peering. >=20 > Perhaps but I don't think we can conclude that as yet. There are most > definitely differences though. I see no reason not to try to take some > of the simplicity and ubiquity of that model and trying to apply it to a > new application where it makes sense. My take is that we need a system that * allows selective peering. If we require that everybody can talk directly to everybody else, we don't get carrier opt-in. * supports branching off into private interconnects. Ideally, all the existing private peering fabrics should fit into the speermint umbrella. * scales to wide adoption, both for SIP URIs / domains as well as peering operators. Nothing in the protocol should preclude that it is used e.g. to get VoIP-enabled PBX systems to peer with each other. (Whether a carrier wants to peer with a PBX is his choice.=20 The protocol shouldn't dictate a peering policy. The contrary: the protocol must support all possible peering policies.) * gives BCPs on how to do the nitty-gritty SIP details (caller-ID, privacy, ...) /ol --=20 < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 30 18:22:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlCbc-0007Zo-LN; Tue, 30 May 2006 18:22:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlCbc-0007Zj-46 for speermint@ietf.org; Tue, 30 May 2006 18:22:28 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FlCba-0003R8-Kb for speermint@ietf.org; Tue, 30 May 2006 18:22:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Wed, 31 May 2006 00:26:32 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A96@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaEEj+xq4NJjpNHTX6tBBrxkLHM4QAIH9XZ From: "Stastny Richard" To: "Otmar Lendl" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org =20 Otmar wrote: >My take is that we need a system that >* allows selective peering. If we require that everybody can talk > directly to everybody else, we don't get carrier opt-in. >* supports branching off into private interconnects. > Ideally, all the existing private peering fabrics should fit > into the speermint umbrella. >* scales to wide adoption, both for SIP URIs / domains as well as > peering operators. > Nothing in the protocol should preclude that it is used e.g. > to get VoIP-enabled PBX systems to peer with each other. >(Whether a carrier wants to peer with a PBX is his choice. >The protocol shouldn't dictate a peering policy. The contrary: >the protocol must support all possible peering policies.) In principle I agree with Otmar, I want only to add some details: =20 All communications (in Speermint) start with an end-user requesting a communication. The user can only do so by entering Public User=20 Identity. This can either be an E.164 number (which is translated via = ENUM to an AoR) or the AoR direct. So we have to start with on AoR. =20 If this AoR is giving the destination domain (hosting the called = end-user) direct and if this can be located by RFC3263 - done (provider or PBX) PBX the = synonym for a direct hosted SIP system) =20 If the AOR is giving a destination domain (e.g. stastny.com) hosted by = e.g. provider.net, we need to "translate" stastny.com to provider.net, e.g with a method = Otmar pointed out in a previous e-mail.=20 =20 Now we have find out how to contact provider.net. =20 provider.net may accept calls from the internet without any polcy - done =20 provider.net may have policies in place, so we have to find out what the = policies are =20 this policies could either be some additional requirements, e.g = providing a certificate accepting calls only from certain provider (federations), accepting = calls only via VPNs, whatever - we have to select and define the options here, = there is a lot of work to be done =20 One of these options could be that provider.net can only be reached via = a "transit network" this could also be announced in the policies, or with local tables of = the originating network, Also here some work is required for the options. =20 Regading a PBX hosted by provider.net, this case seems to get very = complicated, especially if a PBX accepts both calls direct Ifrom selected peers and via = provider.net (the outbound case is simpler, because it is the choice of the PBX to go = direct or via the provider.net as "transit network". This case is similar to the = provider.net itself) =20 In any case, this "dual-mode" direct peering and transit via a provider = is a definite requirement from ECMA (responsible for PBX standards) =20 >* gives BCPs on how to do the nitty-gritty SIP details > (caller-ID, privacy, ...) This is also important. As I already stated, we should define a set of minmum requirements providing features that are approx = equivalent=20 to the minimum requirements of a NNI in the PSTN (e.g. ISUP v2), because this interface will be used as a replacement Some proposals of RFCs have already been made on this list. In words this is basically TLS and CLIP and CLIR (network and user = provided) (=3DP-asserted identity) One last word about E.164 numbers: I said the mapping of E.164 numbers to AoRs is out-of-scope. E.164 numbers in signalling ARE in scope: The information that calls are originating on E.164 numbers or = originally targeted to E.164 numbers should keept intact end-to-end. IMHO all additional issues should go with lower priority (e.g. charge messages, etc) this also never was a big success on the PSTN -sta =20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 30 18:25:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlCe8-0007wH-5k; Tue, 30 May 2006 18:25:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlCe6-0007wC-SL for speermint@ietf.org; Tue, 30 May 2006 18:25:02 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FlCe5-0003TB-Hk for speermint@ietf.org; Tue, 30 May 2006 18:25:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Wed, 31 May 2006 00:27:37 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A97@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaEEdBAV/nhiie0SOG4l7wbr22a4gADATtAAAFX9mAAAJ5/MAABDMqQAAGZpmAAALEUgAABTQCx From: "Stastny Richard" To: "Malas, Daryl" , "Otmar Lendl" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Daryl, =20 I think this is in a nutshell what I just posted more verbose ;-) =20 -sta ________________________________ Von: Malas, Daryl [mailto:Daryl.Malas@Level3.com] Gesendet: Di 30.05.2006 23:53 An: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; speermint@ietf.org Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture After reading my own email, I think I have implied 3 different peering policies (not flows): 1. Private - It is a 1:1 relationship. I peer with you and you with me...no other options...no other routes, etc. 2. Public - I'll peer with anyone 1:*, as long as you meet the policy criteria I have specified. 3. Transit - I am peered to many, but will only allow you to peer with some or all of my peers based on my peers and my policies. Any thoughts?? --Daryl M. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 30 18:37:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlCq7-00051W-RY; Tue, 30 May 2006 18:37:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlCq7-0004yH-26 for speermint@ietf.org; Tue, 30 May 2006 18:37:27 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FlCq6-0004kO-1T for speermint@ietf.org; Tue, 30 May 2006 18:37:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Wed, 31 May 2006 00:41:32 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A98@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaEEdBAV/nhiie0SOG4l7wbr22a4gADATtAAAFX9mAAAJ5/MAABDMqQAAGZpmAAALEUgAAAooFwAAAiHGAAALzvQQ== From: "Stastny Richard" To: "Malas, Daryl" , "Brian Rosen" , X-Spam-Score: 0.0 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org As I pointed out, the definition of transit in SIP is tricky I want to give you an example: =20 A GSMA operator made the following statement regardin GSMA ENUM: =20 Even if we find out via ENUM what the destination network is, the selection hoe we exchange traffic is our choice: It may be via the GSMA IPX network, it may be direct peering, it may be via the Internet, or it may be via a specific transit network for this destination network How they do this? with so-called local routing tables (basically NAPTR records) giiving the peerng path to select in this specific case. =20 This works in principle The drawback of this solution is the local maintenance overhead required, in principle again local routing tables IMHO not a good idea. =20 OTOH, I have currently no idea how to publish these bilateral agreements otherwise =20 -sta ________________________________ Von: Malas, Daryl [mailto:Daryl.Malas@Level3.com] Gesendet: Mi 31.05.2006 00:18 An: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; speermint@ietf.org Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture So, I'm trying to differentiate traditional PSTN transit from SPEERMINT transit. I think the features/extensions of SIP provide a more intelligent capability of transit than traditional TDM/SS7 interconnections. I took your definition (described below) to a "next step up" approach, where my peers and/or my policies may permit transit to only some or all of my peers. ...I suppose, your definition does work; because, technically my other peers do not exist to you if I don't allow you to transit to them due to my policies or theirs. Sorry, it's a little confusing, but I hope it makes sense. I may be breaking the traditional term of transit, but I think it fits the capability the closest. If you can come up with a better "summarizing" term, I'm listening. ;-) --Daryl M. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, May 30, 2006 4:10 PM To: Malas, Daryl; 'Pfautz, Penn L, GBLAM'; 'Otmar Lendl'; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture I don't like your definition of "transit". Transit means "I am peered to others, and they will permit me to let you get to them through me".=20 Brian -----Original Message----- From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] Sent: Tuesday, May 30, 2006 5:54 PM To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture After reading my own email, I think I have implied 3 different peering policies (not flows): 1. Private - It is a 1:1 relationship. I peer with you and you with me...no other options...no other routes, etc. 2. Public - I'll peer with anyone 1:*, as long as you meet the policy criteria I have specified. 3. Transit - I am peered to many, but will only allow you to peer with some or all of my peers based on my peers and my policies. Any thoughts?? --Daryl M. -----Original Message----- From: Malas, Daryl Sent: Tuesday, May 30, 2006 3:43 PM To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture I was thinking in terms of Contradiction 2 (if I'm reading your list correctly)...B won't tell A about it's routes to C and D, because B has negotiated a "private" relationship with A. In this case, A can only route to B (and D via it's other "private" relationship). In this case, I am not describing a transit scenario with B. B simply has multiple peering relationships with varying types of peering partners (public or open vs. private). Now please don't confuse the internet as implying a public peering relationship, although that is what I intended for this example. The internet is simply a layer 3 mechanism, and a private peering relationship could exist via that path as well. Peering can and should be architected to work in a transit scenario as well, as you began to describe below. A peers with B, because it knows B is peered with many federations or domains. In this case, B is acting as a transit or termination peering hub to multiple spokes (if I can use that analogy liberally) -- B may also have domains associated with it. Also, A could still maintain a private peering relationship with D, to create multiple layer 5 path choices for getting to D. For example, D may be peered with a DS-3 with high levels of quality (e.g. diffserv, ToS, etc.), while the peering relationship to B may be an OC-12 without quality guarantees. A's primary choice to D is via it's private peering relationship to D, and a secondary choice is through B. This is getting fairly complex, but all of these are good to hash out in the architecture document...otherwise, the industry will run with crazy one-offs in every different direction causing incompatibilities on several levels. --Daryl -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, May 30, 2006 3:03 PM To: 'Pfautz, Penn L, GBLAM'; Malas, Daryl; 'Otmar Lendl'; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Perhaps we are misinterpreting the figure. I am interpreting C as accepting calls over the Internet from any domain (that is, not limited to specific peers). I'm not just thinking that the peering fabric is the Internet; of course any connection between peers can traverse the Internet. I assume A knows it wants a route to C. ENUM is out of scope. The Route Advertisement is what domains B tells A it can get to, so that A knows B can get to C. Contradiction 1 is that if C is known to accept connections from any domain, then B is not adding value. It can't be a secret only known to B that C accepts any connections. Contradiction 2 is that B can't tell A that it can reach all possible C's. A specific C, maybe, but then you are back to Contradiction 1. Let's be more concrete. Suppose there is an enterprise with a SIP PBX. Suppose it starts out by purchasing VoIP termination services from a carrier and sends all its traffic there, and to start, only accepts traffic from its carrier. Now, suppose that at some point the enterprise gets comfortable and starts allowing traffic from the Internet direct to its PBX. Suppose, just to get it off the table, that there is public ENUM, so number services are not an issue. This enterprise is now a "C". How does B tell A that it can get to C? How does it know that? Generally, C freely "advertises" its "route" by simply putting an SRV record in its public DNS. What is the way A "seeks a route to C" by any mechanism short of just trying DNS. What I'm getting at is that B can't make a definitive list of all the C's out there, and there is no wildcard that works. =20 Brian -----Original Message----- From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] Sent: Tuesday, May 30, 2006 4:20 PM To: Brian Rosen; Malas, Daryl; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Sorry, sent too soon... This is the kind of thing that makes we wonder why anyone wants to look at this in terms of route advertisement where A doesn't know the destination is C and just looks at what B says it can reach. I can imagine that A knows the ultimate destination is C and then seeks a route to C, which would eliminate the contradictions Brian raises. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, May 30, 2006 4:02 PM To: 'Malas, Daryl'; 'Otmar Lendl'; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture I am absolutely certain that these kinds of arrangements will be seen "in the wild". Two thoughts strike me: 1) If Domain A is paying Domain B a lot for this kind of service, it may need a software update so it can do it itself 2) The route advertisement from B towards A gets REALLY tricky. The reason is that there is no convenient way to express it. It's not "*" (I can get you to any domain). It's "I can get you to any domain that accepts connections from the Internet". It's the terminating network that decides if it will allow traffic from some other domain, and "Domain B" below, doesn't know what the rules for Domain C are. Brian -----Original Message----- From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] Sent: Tuesday, May 30, 2006 3:45 PM To: Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture In addition to your comments below, I think peering will likely occur in one of the following methods or all of them (this includes the capabilities described in the Peering Architecture Draft: +---------+ | | +--------+ +--------+ +------------+ /|Domain C | | | | | / \ / | | |Domain A| Private |Domain B| Public | Internet |/ +---------+ | |=3D=3D=3D=3D=3D=3D=3D=3D=3D| = |=3D=3D=3D=3D=3D=3D=3D=3D=3D| |\ | | Peer | | Peer \ / \ +---------+ +--------+ +--------+ +------------+ \| | || |Domain D | =20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D| |=20 Private Peer +---------+ As far as PBX interconnect goes... I don't think SPEERMINT should design a tie-line replacement architecture. IMO, it is out of scope. I know this becomes somewhat blurry, as more SIP PBX's are a conglomeration of multiple SIP capabilities (e.g. UA, UAS, Proxy, etc.), some of which are described in the architecture. However, the SIP Forum is already addressing many of those concerns in SIP Forum drafts such as: sf-draft-twg-IP_PBX_SP_Interop-sibley-v5.pdf. My two cents... =20 --Daryl M. -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at] Sent: Tuesday, May 30, 2006 11:51 AM To: speermint@ietf.org Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture On 2006/05/30 19:05, "Livingood, Jason" wrote: > > I believe this discussion has gone over the edge. > > > > The reason SPEERMINT exists is that CARRIERS want to peer. > > Perhaps a fair assessment, but I suspect we all would like it to > progress beyond that.=20 >=20 > > Email is an inappropriate metaphor for carrier peering. > > Perhaps but I don't think we can conclude that as yet. There are most > definitely differences though. I see no reason not to try to take some > of the simplicity and ubiquity of that model and trying to apply it to a > new application where it makes sense. My take is that we need a system that * allows selective peering. If we require that everybody can talk directly to everybody else, we don't get carrier opt-in. * supports branching off into private interconnects. Ideally, all the existing private peering fabrics should fit into the speermint umbrella. * scales to wide adoption, both for SIP URIs / domains as well as peering operators. Nothing in the protocol should preclude that it is used e.g. to get VoIP-enabled PBX systems to peer with each other. (Whether a carrier wants to peer with a PBX is his choice. The protocol shouldn't dictate a peering policy. The contrary: the protocol must support all possible peering policies.) * gives BCPs on how to do the nitty-gritty SIP details (caller-ID, privacy, ...) /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue May 30 21:50:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlFqD-00058s-Bv; Tue, 30 May 2006 21:49:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlFqC-00058m-PV for speermint@ietf.org; Tue, 30 May 2006 21:49:44 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlFqB-0007uR-9h for speermint@ietf.org; Tue, 30 May 2006 21:49:44 -0400 Received: from PMelampy [68.189.242.21] by acmepacket.com with ESMTP (SMTPD-9.03) id A625039C; Tue, 30 May 2006 21:49:25 -0400 From: "Patrick Melampy" To: "'Brian Rosen'" , Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 30 May 2006 21:49:29 -0400 Message-ID: <054c01c68454$755175f0$0202fea9@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaEEdBAV/nhiie0SOG4l7wbr22a4gADATtAAAFX9mAAAJ5/MAABDMqQAAkbAvA= In-Reply-To: <04d901c6842c$6c63b8e0$640fa8c0@cis.neustar.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org B's value (which you seem to completely be disregarding) isn't solely that he can forward SIP messages directly to C -- more importantly, C trust's B that B will only forward TRUSTED communication to C. Thus the chain of identity asserted, trusted communication, can only work when untrusted networks and proxies are either excluded, or clearly identified as untrusted. Speaking of enterprises...I bet very few will connect their IP PBX to the public internet. I suspect they will connect these types of systems only to proxies and sources of inbound communications requests that they trust. This group needs to be focused on developing schemes for "connecting" these proxies into trusted chains. I believe that an advertisement mechanism (subscribe/notify) can meet this requirement. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, May 30, 2006 5:03 PM To: 'Pfautz, Penn L, GBLAM'; 'Malas, Daryl'; 'Otmar Lendl'; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Perhaps we are misinterpreting the figure. I am interpreting C as accepting calls over the Internet from any domain (that is, not limited to specific peers). I'm not just thinking that the peering fabric is the Internet; of course any connection between peers can traverse the Internet. I assume A knows it wants a route to C. ENUM is out of scope. The Route Advertisement is what domains B tells A it can get to, so that A knows B can get to C. Contradiction 1 is that if C is known to accept connections from any domain, then B is not adding value. It can't be a secret only known to B that C accepts any connections. Contradiction 2 is that B can't tell A that it can reach all possible C's. A specific C, maybe, but then you are back to Contradiction 1. Let's be more concrete. Suppose there is an enterprise with a SIP PBX. Suppose it starts out by purchasing VoIP termination services from a carrier and sends all its traffic there, and to start, only accepts traffic from its carrier. Now, suppose that at some point the enterprise gets comfortable and starts allowing traffic from the Internet direct to its PBX. Suppose, just to get it off the table, that there is public ENUM, so number services are not an issue. This enterprise is now a "C". How does B tell A that it can get to C? How does it know that? Generally, C freely "advertises" its "route" by simply putting an SRV record in its public DNS. What is the way A "seeks a route to C" by any mechanism short of just trying DNS. What I'm getting at is that B can't make a definitive list of all the C's out there, and there is no wildcard that works. Brian -----Original Message----- From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] Sent: Tuesday, May 30, 2006 4:20 PM To: Brian Rosen; Malas, Daryl; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Sorry, sent too soon... This is the kind of thing that makes we wonder why anyone wants to look at this in terms of route advertisement where A doesn't know the destination is C and just looks at what B says it can reach. I can imagine that A knows the ultimate destination is C and then seeks a route to C, which would eliminate the contradictions Brian raises. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, May 30, 2006 4:02 PM To: 'Malas, Daryl'; 'Otmar Lendl'; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture I am absolutely certain that these kinds of arrangements will be seen "in the wild". Two thoughts strike me: 1) If Domain A is paying Domain B a lot for this kind of service, it may need a software update so it can do it itself 2) The route advertisement from B towards A gets REALLY tricky. The reason is that there is no convenient way to express it. It's not "*" (I can get you to any domain). It's "I can get you to any domain that accepts connections from the Internet". It's the terminating network that decides if it will allow traffic from some other domain, and "Domain B" below, doesn't know what the rules for Domain C are. Brian -----Original Message----- From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] Sent: Tuesday, May 30, 2006 3:45 PM To: Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture In addition to your comments below, I think peering will likely occur in one of the following methods or all of them (this includes the capabilities described in the Peering Architecture Draft: +---------+ | | +--------+ +--------+ +------------+ /|Domain C | | | | | / \ / | | |Domain A| Private |Domain B| Public | Internet |/ +---------+ | |=========| |=========| |\ | | Peer | | Peer \ / \ +---------+ +--------+ +--------+ +------------+ \| | || |Domain D | =======================================================| | Private Peer +---------+ As far as PBX interconnect goes... I don't think SPEERMINT should design a tie-line replacement architecture. IMO, it is out of scope. I know this becomes somewhat blurry, as more SIP PBX's are a conglomeration of multiple SIP capabilities (e.g. UA, UAS, Proxy, etc.), some of which are described in the architecture. However, the SIP Forum is already addressing many of those concerns in SIP Forum drafts such as: sf-draft-twg-IP_PBX_SP_Interop-sibley-v5.pdf. My two cents... --Daryl M. -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at] Sent: Tuesday, May 30, 2006 11:51 AM To: speermint@ietf.org Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture On 2006/05/30 19:05, "Livingood, Jason" wrote: > > I believe this discussion has gone over the edge. > > > > The reason SPEERMINT exists is that CARRIERS want to peer. > > Perhaps a fair assessment, but I suspect we all would like it to > progress beyond that. > > > Email is an inappropriate metaphor for carrier peering. > > Perhaps but I don't think we can conclude that as yet. There are most > definitely differences though. I see no reason not to try to take some > of the simplicity and ubiquity of that model and trying to apply it to a > new application where it makes sense. My take is that we need a system that * allows selective peering. If we require that everybody can talk directly to everybody else, we don't get carrier opt-in. * supports branching off into private interconnects. Ideally, all the existing private peering fabrics should fit into the speermint umbrella. * scales to wide adoption, both for SIP URIs / domains as well as peering operators. Nothing in the protocol should preclude that it is used e.g. to get VoIP-enabled PBX systems to peer with each other. (Whether a carrier wants to peer with a PBX is his choice. The protocol shouldn't dictate a peering policy. The contrary: the protocol must support all possible peering policies.) * gives BCPs on how to do the nitty-gritty SIP details (caller-ID, privacy, ...) /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 31 02:15:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlJyq-0007YF-1x; Wed, 31 May 2006 02:14:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlJyo-0007YA-Rl for speermint@ietf.org; Wed, 31 May 2006 02:14:54 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlJyn-00073A-Dn for speermint@ietf.org; Wed, 31 May 2006 02:14:54 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 4A8B41A36D; Wed, 31 May 2006 08:14:50 +0200 (CEST) Date: Wed, 31 May 2006 08:14:50 +0200 From: Otmar Lendl To: Patrick Melampy Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Message-ID: <20060531061449.GQ1811@nic.at> Mail-Followup-To: Otmar Lendl , Patrick Melampy , 'Brian Rosen' , speermint@ietf.org References: <04d901c6842c$6c63b8e0$640fa8c0@cis.neustar.com> <054c01c68454$755175f0$0202fea9@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <054c01c68454$755175f0$0202fea9@acmepacket.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/05/31 03:05, Patrick Melampy wrote: > > B's value (which you seem to completely be disregarding) isn't solely that > he can forward SIP messages directly to C -- more importantly, C trust's B > that B will only forward TRUSTED communication to C. Thus the chain of > identity asserted, trusted communication, can only work when untrusted > networks and proxies are either excluded, or clearly identified as > untrusted. Correct. > Speaking of enterprises...I bet very few will connect their IP PBX to the > public internet. You've got to distinuish "public internet" on layer 3 from open SIP proxy on the Internet. Right now, some of the enum.at registrars are happily selling VoIP-based PBX installations to enterprises which peer with each other automatically based on User-ENUM and open SIP URIs. > I suspect they will connect these types of systems only to > proxies and sources of inbound communications requests that they trust. That's one of the examples of my "federation" draft. E.g. take the MPAA as a typical industry association: If they run a X.509 certification authority (incl. revocation lists) which signs the TLS certs of the PBXs of member organizations then all the telephone systems of Hollywood can peer with each other over the open Internet in a secure fashion. Whatever Speermint comes up with: such a scenario must IMHO be supported. > This group needs to be focused on developing schemes for "connecting" these > proxies into trusted chains. I believe that an advertisement mechanism > (subscribe/notify) can meet this requirement. As mentioned before, (subscribe/notify) is very nice for manually configured relationsships. I don't see how you implement the guild example from above with that concept. Please elaborate. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 31 07:46:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlP9V-0007Wn-Me; Wed, 31 May 2006 07:46:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlP9U-0007Wi-QU for speermint@ietf.org; Wed, 31 May 2006 07:46:16 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlP9S-0004Z4-G2 for speermint@ietf.org; Wed, 31 May 2006 07:46:16 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FlP9M-0004Jt-6n; Wed, 31 May 2006 06:46:08 -0500 From: "Brian Rosen" To: "'Otmar Lendl'" , "'Patrick Melampy'" Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Wed, 31 May 2006 07:46:08 -0400 Message-ID: <060301c684a7$d0979e00$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20060531061449.GQ1811@nic.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaEeYaNTR7pxrKrSHuhvF5AUf/YpQALGiCQ X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Oh, I really expect to see most connections through carriers for quite a while. I do wonder if "trust" is something transit networks can actually help with. I believe in identity, and identity has to be asserted by someone. One reasonable source of trusted identity is the originating carrier. That is an enduring value; if a carrier does little more than provide a reliable identity, that will help avoid SPIT. However, it seems hard to me for a transit network to provide a trust chain stronger than a direct connections. Maybe this is wrapped up in what you call "trusted communications". What is the assertion that B is making about A that C cares about? One of the things that we have to face is that most of us WILL accept a call from someone we don't know. We balance the risk of being annoyed or offended against the risk of discovering something new that we like. A business, as an example, doesn't want to miss a call from a new customer, so it always accepts calls directed to its general sales line from anyone. We have to deal with identity, which is one of the trust characteristics an originator provides to a terminator. What else are we trusting? Brian -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at] Sent: Wednesday, May 31, 2006 2:15 AM To: Patrick Melampy Cc: 'Brian Rosen'; speermint@ietf.org Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture On 2006/05/31 03:05, Patrick Melampy wrote: > > B's value (which you seem to completely be disregarding) isn't solely that > he can forward SIP messages directly to C -- more importantly, C trust's B > that B will only forward TRUSTED communication to C. Thus the chain of > identity asserted, trusted communication, can only work when untrusted > networks and proxies are either excluded, or clearly identified as > untrusted. Correct. > Speaking of enterprises...I bet very few will connect their IP PBX to the > public internet. You've got to distinuish "public internet" on layer 3 from open SIP proxy on the Internet. Right now, some of the enum.at registrars are happily selling VoIP-based PBX installations to enterprises which peer with each other automatically based on User-ENUM and open SIP URIs. > I suspect they will connect these types of systems only to > proxies and sources of inbound communications requests that they trust. That's one of the examples of my "federation" draft. E.g. take the MPAA as a typical industry association: If they run a X.509 certification authority (incl. revocation lists) which signs the TLS certs of the PBXs of member organizations then all the telephone systems of Hollywood can peer with each other over the open Internet in a secure fashion. Whatever Speermint comes up with: such a scenario must IMHO be supported. > This group needs to be focused on developing schemes for "connecting" these > proxies into trusted chains. I believe that an advertisement mechanism > (subscribe/notify) can meet this requirement. As mentioned before, (subscribe/notify) is very nice for manually configured relationsships. I don't see how you implement the guild example from above with that concept. Please elaborate. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 31 08:16:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlPcV-0003pf-F3; Wed, 31 May 2006 08:16:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlPcT-0003pa-W3 for speermint@ietf.org; Wed, 31 May 2006 08:16:13 -0400 Received: from [204.209.140.176] (helo=wodka.aus-biz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlPcR-0006wR-MU for speermint@ietf.org; Wed, 31 May 2006 08:16:13 -0400 Received: from [192.168.1.101] (cpe-24-95-54-117.columbus.res.rr.com [24.95.54.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Duane Groth", Issuer "CAcert Class 3 Root" (not verified)) by wodka.aus-biz.com (Postfix) with ESMTP id 285292CD9; Wed, 31 May 2006 08:16:07 -0400 (EDT) Message-ID: <447D8903.4050807@e164.org> Date: Wed, 31 May 2006 08:16:03 -0400 From: Duane User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture References: <060301c684a7$d0979e00$640fa8c0@cis.neustar.com> In-Reply-To: <060301c684a7$d0979e00$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian Rosen wrote: > One of the things that we have to face is that most of us WILL accept a call > from someone we don't know. We balance the risk of being annoyed or > offended against the risk of discovering something new that we like. A > business, as an example, doesn't want to miss a call from a new customer, so > it always accepts calls directed to its general sales line from anyone. I think things won't be as bad as they are now, if in future people can run a small pbx to filter their calls, so rather then cold calls being automated in a fashion they are now telemarketers will need to listed to menu options before being connected to a person (this particular method drops most cold calls I've found, since the system answers and waits for input but the telemarketer doesn't hit it in time so the system trashes the call. I liked the X.509 certs on TLS connections idea as well, and in the case of CID being in enum you could also do a reverse lookup and/or some other record type to determine where calls are supposed to come from (I hate to say it - "SPF style"). Although if some kind of CID verification is establish at this point in time things might not get out of hand like they have with email. -- Best regards, Duane _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 31 08:36:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlPvi-0003Ep-Of; Wed, 31 May 2006 08:36:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlPvi-0003Ek-4V for speermint@ietf.org; Wed, 31 May 2006 08:36:06 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlPvg-0007yv-PW for speermint@ietf.org; Wed, 31 May 2006 08:36:06 -0400 Received: from ([10.20.9.172]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.20676261; Wed, 31 May 2006 08:35:55 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 08:35:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Wed, 31 May 2006 08:35:53 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96624766@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaEeYaNTR7pxrKrSHuhvF5AUf/YpQALGiCQAAD+ZiA= From: "Lee, Yiu" To: "Brian Rosen" , "Otmar Lendl" , "Patrick Melampy" X-OriginalArrivalTime: 31 May 2006 12:35:55.0344 (UTC) FILETIME=[C2C40500:01C684AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian, I agree that most people will accept unknown calls to discover something new. However, we have to admit that some people in this world abuse our curiosity. I think the last thing we want to have is building a system that allows spammers to spam sip sessions like the way they spam emails. Since many people in this list (including myself) compare sip peering to email system, we need to define some way to protect ourselves. Asserted identity is a very good approach. I can at least complain to my service provider when I received a spam call and my service provider will be able to trace down the caller from the asserted identity. To prevent from receiving 10000 "unknown" calls per day, I will probably only accept calls routed from my service provider rather than accepting any call routed from public/unknown proxies directly to me. I will rely on my service provider to accept calls only with valid asserted identity. I expect that my service provider will probably sign some bi-lateral agreement with other peering service providers to enforce policies for asserted identity. Of course, this is only my choice. Other people can decide to open up their proxies and accept calls from anywhere. For Domain C, I think at minimum C cares if A's Id is asserted by Domain B. So, if C wants to trace back A for any reason, he will have a way. Regards, Yiu -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, May 31, 2006 7:46 AM To: 'Otmar Lendl'; 'Patrick Melampy' Cc: speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Oh, I really expect to see most connections through carriers for quite a while. I do wonder if "trust" is something transit networks can actually help with. I believe in identity, and identity has to be asserted by someone. One reasonable source of trusted identity is the originating carrier. That is an enduring value; if a carrier does little more than provide a reliable identity, that will help avoid SPIT. However, it seems hard to me for a transit network to provide a trust chain stronger than a direct connections. Maybe this is wrapped up in what you call "trusted communications". What is the assertion that B is making about A that C cares about? One of the things that we have to face is that most of us WILL accept a call from someone we don't know. We balance the risk of being annoyed or offended against the risk of discovering something new that we like. A business, as an example, doesn't want to miss a call from a new customer, so it always accepts calls directed to its general sales line from anyone. =20 We have to deal with identity, which is one of the trust characteristics an originator provides to a terminator. What else are we trusting? Brian -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at] Sent: Wednesday, May 31, 2006 2:15 AM To: Patrick Melampy Cc: 'Brian Rosen'; speermint@ietf.org Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture On 2006/05/31 03:05, Patrick Melampy wrote: >=20 > B's value (which you seem to completely be disregarding) isn't solely=20 > that he can forward SIP messages directly to C -- more importantly, C=20 > trust's B that B will only forward TRUSTED communication to C. Thus=20 > the chain of identity asserted, trusted communication, can only work=20 > when untrusted networks and proxies are either excluded, or clearly=20 > identified as untrusted. Correct. > Speaking of enterprises...I bet very few will connect their IP PBX to=20 > the public internet. You've got to distinuish "public internet" on layer 3 from open SIP proxy on the Internet. Right now, some of the enum.at registrars are happily selling VoIP-based PBX installations to enterprises which peer with each other automatically based on User-ENUM and open SIP URIs. > I suspect they will connect these types of systems=20 > only to > proxies and sources of inbound communications requests that they trust. That's one of the examples of my "federation" draft. E.g. take the MPAA as a typical industry association: If they run a X.509 certification authority (incl. revocation lists) which signs the TLS certs of the PBXs of member organizations then all the telephone systems of Hollywood can peer with each other over the open Internet in a secure fashion. Whatever Speermint comes up with: such a scenario must IMHO be supported. > This group needs to be focused on developing schemes for "connecting" these > proxies into trusted chains. I believe that an advertisement mechanism > (subscribe/notify) can meet this requirement. As mentioned before, (subscribe/notify) is very nice for manually configured relationsships. I don't see how you implement the guild example from above with that concept.=20 Please elaborate. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 31 08:41:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlQ12-0004ma-Cf; Wed, 31 May 2006 08:41:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlQ0j-0004lx-Pa for speermint@ietf.org; Wed, 31 May 2006 08:41:18 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FlQ0j-000070-2B for speermint@ietf.org; Wed, 31 May 2006 08:41:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Wed, 31 May 2006 14:45:17 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4FF1@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaEeYaNTR7pxrKrSHuhvF5AUf/YpQALGiCQAAFxExA= From: "Stastny Richard" To: "Brian Rosen" X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Thanks Brian that you finally made it clear that the whole issue of VoIP peering is about trust and identity. > One of the things that we have to face is that most of us WILL accept a > call > from someone we don't know. We balance the risk of being annoyed or > offended against the risk of discovering something new that we like. A > business, as an example, doesn't want to miss a call from a new customer, > so > it always accepts calls directed to its general sales line from anyone. Exactly The problem here is that we talk about two layers of trust: One is the end-to-end trust between the end-users and the other is the commercial and policy trust between the providers. I think our problem is partially derived that we always mix these two issues. There is also different kind of identities. An example: In normal communications as an end-user I just want to know that a Brian Rosen contacting me is really the Brian Rosen I know, if I do not know you I want to have some assertion that this is your real name, or at least I want to have some guaranty that I could find out. This requires some kind of third party to be able to retrieve=20 this information on request. But this does not imply if you sell me something that I will get my money ;-). Ok, with the identity given I my find out enough to sue you, but this is very complicated. So if I make business with you, I basically do not care if you are really Brian Rosen as long as I get my money. This required another kind of third party, somebody guarantying me the money on behalf of you. This is basically the trust relationship also the service providers need. So for guarantying the identity for end-users in the first case, we simply need some trusted third party, which could be the originating service provider=20 providing a P-asserted identity. If I am then be happy to connect via the Internet with best effort,=20 this is none of the service provides issue. We simply need same basic requirements to securely transmit the identities. So what is all this fuzz about only excepting calls from certain providers, only via VPNs, direct peerings, not trusting the Internet, etc. It is all about the business trust layer between operators, e.g. to get termination charges, service charges, service level agreements, etc. This does not help the end-user very much. Also the transit issue is only for provider trust The end-user trust is end-to-end, if the minimum requirements are kept between all providers in the chain, it does not matter. (OTOH one could ask why a transit network is required in this case) The transit trust is required if money is involved, e.g. termination fees: C is not trusting A that he will pay termination fees, because they have no agreement. C trusts B,=20 because they have one. If now C trusts B, he does not care anymore about A. B is basically a clearing house. In policy terms: A is looking up the policy federation of C and finds out it a member of federation X. A now looks for a provider he has an agreement with, and is also member of X which in this case is B. So A forwards the call to B because A can assume that B is able to deliver the call to C. B is trusted by C to pay and also trusts A to get the money back -sta > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, May 31, 2006 1:46 PM > To: 'Otmar Lendl'; 'Patrick Melampy' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > Oh, I really expect to see most connections through carriers for quite a > while. I do wonder if "trust" is something transit networks can actually > help with. >=20 > I believe in identity, and identity has to be asserted by someone. One > reasonable source of trusted identity is the originating carrier. That is > an enduring value; if a carrier does little more than provide a reliable > identity, that will help avoid SPIT. >=20 > However, it seems hard to me for a transit network to provide a trust > chain > stronger than a direct connections. Maybe this is wrapped up in what you > call "trusted communications". What is the assertion that B is making > about > A that C cares about? >=20 > One of the things that we have to face is that most of us WILL accept a > call > from someone we don't know. We balance the risk of being annoyed or > offended against the risk of discovering something new that we like. A > business, as an example, doesn't want to miss a call from a new customer, > so > it always accepts calls directed to its general sales line from anyone. >=20 > We have to deal with identity, which is one of the trust characteristics > an > originator provides to a terminator. What else are we trusting? >=20 > Brian >=20 > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Wednesday, May 31, 2006 2:15 AM > To: Patrick Melampy > Cc: 'Brian Rosen'; speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > On 2006/05/31 03:05, Patrick Melampy wrote: > > > > B's value (which you seem to completely be disregarding) isn't solely > that > > he can forward SIP messages directly to C -- more importantly, C trust's > B > > that B will only forward TRUSTED communication to C. Thus the chain of > > identity asserted, trusted communication, can only work when untrusted > > networks and proxies are either excluded, or clearly identified as > > untrusted. >=20 > Correct. >=20 > > Speaking of enterprises...I bet very few will connect their IP PBX to > the > > public internet. >=20 > You've got to distinuish "public internet" on layer 3 from open SIP > proxy on the Internet. Right now, some of the enum.at registrars are > happily selling VoIP-based PBX installations to enterprises which > peer with each other automatically based on User-ENUM and open SIP URIs. >=20 > > I suspect they will connect these types of systems only > to > > proxies and sources of inbound communications requests that they trust. >=20 > That's one of the examples of my "federation" draft. E.g. take the > MPAA as a typical industry association: If they run a X.509 > certification authority (incl. revocation lists) which signs the > TLS certs of the PBXs of member organizations then all the > telephone systems of Hollywood can peer with each other over the > open Internet in a secure fashion. >=20 > Whatever Speermint comes up with: such a scenario must IMHO be supported. >=20 > > This group needs to be focused on developing schemes for "connecting" > these > > proxies into trusted chains. I believe that an advertisement mechanism > > (subscribe/notify) can meet this requirement. >=20 > As mentioned before, (subscribe/notify) is very nice for manually > configured relationsships. I don't see how you implement > the guild example from above with that concept. >=20 > Please elaborate. >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 31 09:19:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlQb3-0003tf-AW; Wed, 31 May 2006 09:18:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlQb2-0003ta-4b for speermint@ietf.org; Wed, 31 May 2006 09:18:48 -0400 Received: from outbound-fra.frontbridge.com ([62.209.45.174] helo=outbound1-fra-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlQb0-0003TH-Lp for speermint@ietf.org; Wed, 31 May 2006 09:18:48 -0400 Received: from outbound1-fra.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-fra-R.bigfish.com (Postfix) with ESMTP id 23F70653F69; Wed, 31 May 2006 13:18:46 +0000 (UTC) Received: from mail65-fra-R.bigfish.com (unknown [172.18.18.1]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by outbound1-fra.bigfish.com (Postfix) with ESMTP id 1A39A653F8D; Wed, 31 May 2006 13:18:46 +0000 (UTC) Received: from mail65-fra.bigfish.com (localhost.localdomain [127.0.0.1]) by mail65-fra-R.bigfish.com (Postfix) with ESMTP id 0898443EB2F; Wed, 31 May 2006 13:18:46 +0000 (UTC) X-BigFish: V Received: by mail65-fra (MessageSwitch) id 11490815262131_4856; Wed, 31 May 2006 13:18:46 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail65-fra.bigfish.com (Postfix) with ESMTP id B978643ED37; Wed, 31 May 2006 13:18:45 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k4VDIiAg004821; Wed, 31 May 2006 08:18:44 -0500 (CDT) Received: from pdawg06a.ad.sprint.com (PDAWG06A.corp.sprint.com [10.122.2.33]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k4VDIh216536; Wed, 31 May 2006 08:18:44 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by pdawg06a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 08:17:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Wed, 31 May 2006 08:17:57 -0500 Message-ID: <978886E57CC1D64EAFAC157B98E36F9E092EA03B@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaErCEw5Iw8cKdwRV6Riz/ThwmMFAAB58aw From: "Khan, Sohel Q [CTO]" To: "Duane" , "Brian Rosen" X-OriginalArrivalTime: 31 May 2006 13:17:57.0984 (UTC) FILETIME=[A2605600:01C684B4] X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Duane, Many people prefer their providers perform call filtering. For example, cell phone users prefer that SPAMs are filtered by the cell phone providers.=20 Filtering in the provider's network instead of filtering in the cell phone saves expensive wireless bandwidth. Also, in some countries, there are regulations that cell phone providers filter SPAMs. Sohel=20 -----Original Message----- From: Duane [mailto:duane@e164.org]=20 Sent: Wednesday, May 31, 2006 7:16 AM To: Brian Rosen Cc: speermint@ietf.org Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Brian Rosen wrote: > One of the things that we have to face is that most of us WILL accept=20 > a call from someone we don't know. We balance the risk of being=20 > annoyed or offended against the risk of discovering something new that > we like. A business, as an example, doesn't want to miss a call from=20 > a new customer, so it always accepts calls directed to its general sales line from anyone. I think things won't be as bad as they are now, if in future people can run a small pbx to filter their calls, so rather then cold calls being automated in a fashion they are now telemarketers will need to listed to menu options before being connected to a person (this particular method drops most cold calls I've found, since the system answers and waits for input but the telemarketer doesn't hit it in time so the system trashes the call. I liked the X.509 certs on TLS connections idea as well, and in the case of CID being in enum you could also do a reverse lookup and/or some other record type to determine where calls are supposed to come from (I hate to say it - "SPF style"). Although if some kind of CID verification is establish at this point in time things might not get out of hand like they have with email. --=20 Best regards, Duane _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 31 10:04:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlRJ3-0005yb-Sc; Wed, 31 May 2006 10:04:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlRJ2-0005yW-7k for speermint@ietf.org; Wed, 31 May 2006 10:04:16 -0400 Received: from [204.209.140.176] (helo=wodka.aus-biz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlRIz-0006x3-UV for speermint@ietf.org; Wed, 31 May 2006 10:04:16 -0400 Received: from [192.168.1.101] (cpe-24-95-54-117.columbus.res.rr.com [24.95.54.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Duane Groth", Issuer "CAcert Class 3 Root" (not verified)) by wodka.aus-biz.com (Postfix) with ESMTP id 158A05A11; Wed, 31 May 2006 10:04:12 -0400 (EDT) Message-ID: <447DA25A.9050500@e164.org> Date: Wed, 31 May 2006 10:04:10 -0400 From: Duane User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: "Lee, Yiu" Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture References: <4884CD6C1DF0A8429DD8DAD942BF9D96624766@PACDCEXCMB03.cable.comcast.com> In-Reply-To: <4884CD6C1DF0A8429DD8DAD942BF9D96624766@PACDCEXCMB03.cable.comcast.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Lee, Yiu wrote: > I agree that most people will accept unknown calls to discover something How's this different from the current system where CID spoofing in the US is so prevalent that companies are actually making a business out of it. I think the future has the ability to reduce, not increase this in the same way people now apply spam filtering to their emails. Although the FCC's DNC list is a nice big stick just the same. -- Best regards, Duane _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed May 31 11:03:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSEI-0005CD-Np; Wed, 31 May 2006 11:03:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSEI-0005C6-7q for speermint@ietf.org; Wed, 31 May 2006 11:03:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlRSC-0007Yw-AM for speermint@ietf.org; Wed, 31 May 2006 10:13:44 -0400 Received: from [204.209.140.176] (helo=wodka.aus-biz.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlRGS-0007yj-Ty for speermint@ietf.org; Wed, 31 May 2006 10:01:41 -0400 Received: from [192.168.1.101] (cpe-24-95-54-117.columbus.res.rr.com [24.95.54.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Duane Groth", Issuer "CAcert Class 3 Root" (not verified)) by wodka.aus-biz.com (Postfix) with ESMTP id BC75D5A11; Wed, 31 May 2006 10:01:30 -0400 (EDT) Message-ID: <447DA1B7.4030205@e164.org> Date: Wed, 31 May 2006 10:01:27 -0400 From: Duane User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: "Khan, Sohel Q [CTO]" Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture References: <978886E57CC1D64EAFAC157B98E36F9E092EA03B@PLSWB08C.ad.sprint.com> In-Reply-To: <978886E57CC1D64EAFAC157B98E36F9E092EA03B@PLSWB08C.ad.sprint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Khan, Sohel Q [CTO] wrote: > Duane, > > Many people prefer their providers perform call filtering. > For example, cell phone users prefer that SPAMs are filtered by the cell > phone providers. > Filtering in the provider's network instead of filtering in the cell > phone saves expensive wireless bandwidth. Also, in some countries, there > are regulations that cell phone providers filter SPAMs. Ummm I thought the regulation put the onus on the SPAMers to filter their own calls or face hefty fines, although to date I think earthlink is the only one that has been fined. -- Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://e164.org - Because e164.arpa is a tax on VoIP "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint