From speermint-bounces@ietf.org Mon Nov 06 18:51:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEEP-0001hj-Gp; Mon, 06 Nov 2006 18:50:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEE6-0001BK-Bq; Mon, 06 Nov 2006 18:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhEE5-0000PA-Om; Mon, 06 Nov 2006 18:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id B516A3289C; Mon, 6 Nov 2006 23:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GhEE5-0004KT-Ih; Mon, 06 Nov 2006 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 06 Nov 2006 18:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-srv-naptr-use-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 --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 : Use of DNS SRV and NAPTR Records for SPEERMINT Author(s) : T. Creighton, G. Khandpur Filename : draft-ietf-speermint-srv-naptr-use-01.txt Pages : 11 Date : 2006-11-6 The objective of this document is to specify the Best Current Practice (BCP) adopted by a service provider providing multimedia communication services such as Voice over Internet Protocol(VoIP) in order to locate another service provider to peer with in the context of Session PEERing for Multimedia INTerconnect. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-srv-naptr-use-01.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-srv-naptr-use-01.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-srv-naptr-use-01.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-11-6162108.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-srv-naptr-use-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-srv-naptr-use-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-6162108.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 Mon Nov 06 22:20:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhHUj-00041c-OO; Mon, 06 Nov 2006 22:19:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhHUi-0003zE-2k for speermint@ietf.org; Mon, 06 Nov 2006 22:19:24 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhHUg-0008NF-NL for speermint@ietf.org; Mon, 06 Nov 2006 22:19:24 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Nov 2006 19:19:22 -0800 X-IronPort-AV: i="4.09,393,1157353200"; d="scan'208"; a="86451679:sNHT62179839" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA73JMxQ001284 for ; Mon, 6 Nov 2006 19:19:22 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA73JMin027999 for ; Mon, 6 Nov 2006 19:19:22 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 19:19:22 -0800 Received: from [130.129.71.49] ([10.21.82.238]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 19:19:21 -0800 Message-ID: <454FFB39.4030104@cisco.com> Date: Mon, 06 Nov 2006 22:19:21 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: speermint@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2006 03:19:21.0910 (UTC) FILETIME=[84D25D60:01C7021B] DKIM-Signature: a=rsa-sha1; q=dns; l=1898; t=1162869562; x=1163733562; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:ICE=20tutorial=3A=20Lunch=20logistics=20update=20[DO=20NOT=20REPLY]; X=v=3Dcisco.com=3B=20h=3Dwvzj+J9U4bGAuwmnCCs9T7HKQa8=3D; b=QydswG02GbPzsAi8GMQzhnIIzJfCTzb+FpHGZnSL43IBJjiseoObCQfTRucG0FV2EO4LZaem lJdvjsM7EaDMsp1RpCrAsPnl+4xTOMl/Dl5M8R2u1d95C0jVLvsWdmHy; Authentication-Results: sj-dkim-3.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Speermint] ICE tutorial: Lunch logistics update [DO NOT REPLY] 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 Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-12.txt) WHEN: Tuesday, November 7 1130-1300 Lunch will be provided at a nominal fee of $10 Sandwiches, salad and chips Bring-your-own beverage Please get me your $10 prior to the end of the IETF meeting. Only 90 lunches have been ordered, its first-come-first-served I am covering this out of my own pocket, so please do get me your $10 if you partake of the food. I'm not tracking who eats or pays - we're on the honor system here! WHERE: Grande Ballroom A WHO: Anyone with an interest in RAI work that would like to learn more about ICE. WHY: ICE is one of the 'core' SIP specifications (according to the SIP hitchhikers guide) and seeing some good adoption. It's the IETF tool for NAT traversal for SIP-based media. However, it's a complex specification. The tutorial will assume only basic familiarity with SIP, SDP and NAT, and explain the rest. Participants will emerge with a high level understanding of the operation of ICE. The tutorial will be based on the pending -12 version. RSVP: Please send a note to me with the Subject line "ice-is-nice" (mailto:jdrosen@cisco.com?Subject=ice-is-nice). !DO NOT REPLY TO THIS NOTE! -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Nov 08 10:38:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhpUU-0002FK-R5; Wed, 08 Nov 2006 10:37:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhpUT-0002F5-Sf for speermint@ietf.org; Wed, 08 Nov 2006 10:37:25 -0500 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhpUQ-0005Px-IK for speermint@ietf.org; Wed, 08 Nov 2006 10:37:25 -0500 Received: from [127.0.0.1] (na.nona.net [::ffff:193.80.224.124]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Wed, 08 Nov 2006 16:37:16 +0100 id 0007C3AA.4551F9AE.00002173 Message-ID: <4551F904.3010108@enum.at> Date: Wed, 08 Nov 2006 16:34:28 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: speermint Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Speermint] PLEASE send your presentations. 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 If you intend to speak during the session today PLEASE send me your slidedeck NOW. So far, there are just 3 out of 9 presentations available at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67 I cannot do minutes and slide deck uploading at the same time, so don't expect me to do that during the session itself. Alex _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Nov 08 18:57:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhxHU-0004o7-Jt; Wed, 08 Nov 2006 18:56:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhxHS-0004mm-PS for speermint@ietf.org; Wed, 08 Nov 2006 18:56:30 -0500 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhxHQ-0000jF-IL for speermint@ietf.org; Wed, 08 Nov 2006 18:56:30 -0500 Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 0CF1F54EC for ; Wed, 8 Nov 2006 18:55:48 -0500 (EST) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy19.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 18:55:47 -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: Wed, 8 Nov 2006 18:55:42 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Charter clarification Thread-Index: AccDkWYAHNmAIaXQT2CojswDoKloSg== From: "Uzelac, Adam" To: X-OriginalArrivalTime: 08 Nov 2006 23:55:47.0687 (UTC) FILETIME=[69675770:01C70391] X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Speermint] Charter clarification 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 like to be sure that I understand correctly the sentiment about Presence/IM being part of the charter: >From the charter: SPEERMINT focuses architectures to identify, signal, and route delay-sensitive (real-time) communication sessions. These sessions use the SIP signaling protocol to enable peering between two or more administrative domains over IP networks. Where these domains peer, or meet, the establishment of trust, security, and a resistance to abuse and attack are all important considerations. Outside of possibly concluding that Presence isn't really a "real-time" communication, but rather status, I believe that the charter doesn't really need to change. IM and Presence should be considered in scope. -AU _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Nov 08 19:18:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghxc4-0000Ga-Lu; Wed, 08 Nov 2006 19:17:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghxc4-0000Dn-5N for speermint@ietf.org; Wed, 08 Nov 2006 19:17:48 -0500 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghxc2-0004wm-V8 for speermint@ietf.org; Wed, 08 Nov 2006 19:17:48 -0500 Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id BCE1C18414 for ; Wed, 8 Nov 2006 19:17:46 -0500 (EST) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy19.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 19:17:46 -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: Wed, 8 Nov 2006 19:17:42 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Source-based routing Thread-Index: AccDlHlStUMBnUcxT1aZYx9SfdE0cQ== From: "Uzelac, Adam" To: X-OriginalArrivalTime: 09 Nov 2006 00:17:46.0379 (UTC) FILETIME=[7B67C5B0:01C70394] X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Speermint] Source-based routing 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, I would like to propose that we add to the list of requirements for SPEERMINT that any session routing proposal that is proposed take into account the ability to use some source criteria to return next-hop routes. I just re-read the requirements draft, and I did not see anything specifically addressing source-based routing.=20 Speaking as a VSP, it's important that the ingress session border element that is returned to the originator of the request be based on, among other things, who's asking and from where. In practice, we do not return next-hop information irrespective if the request comes from Alice/Bob, or from China/Brazil. This may be a matter of local policy, but the tools and IDs that address session next-hop determination need to account for this. -AU _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Nov 08 19:24:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghxi0-0004CP-KD; Wed, 08 Nov 2006 19:23:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghxhy-0004CH-Ju for speermint@ietf.org; Wed, 08 Nov 2006 19:23:54 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghxhv-000620-7V for speermint@ietf.org; Wed, 08 Nov 2006 19:23:54 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 08 Nov 2006 16:21:00 -0800 X-IronPort-AV: i="4.09,401,1157353200"; d="scan'208"; a="616371513:sNHT40651284" 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] Source-based routing Date: Wed, 8 Nov 2006 19:23:51 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280624F010@proton.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing Thread-index: AccDlHlStUMBnUcxT1aZYx9SfdE0cQAAJbBA From: "Reinaldo Penno" To: "Uzelac, Adam" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Although I'm not a VSP I agree. At some point we discussed on this the fact that identity/geography/others should be taken into account when discovering/returning next-hop. That kind of faded way but seems a real problem to be tackled. Regards, Reinaldo > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 > Sent: Wednesday, November 08, 2006 4:18 PM > To: speermint@ietf.org > Subject: [Speermint] Source-based routing >=20 > Folks, >=20 > I would like to propose that we add to the list of=20 > requirements for SPEERMINT that any session routing proposal=20 > that is proposed take into account the ability to use some=20 > source criteria to return next-hop routes. I just re-read the=20 > requirements draft, and I did not see anything specifically=20 > addressing source-based routing.=20 >=20 > Speaking as a VSP, it's important that the ingress session=20 > border element that is returned to the originator of the=20 > request be based on, among other things, who's asking and=20 > from where. In practice, we do not return next-hop=20 > information irrespective if the request comes from Alice/Bob,=20 > or from China/Brazil. This may be a matter of local policy,=20 > but the tools and IDs that address session next-hop=20 > determination need to account for this. >=20 > -AU >=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 Nov 08 22:08:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi0Gc-0006bZ-1u; Wed, 08 Nov 2006 22:07:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi0Ga-0006bH-U5 for speermint@ietf.org; Wed, 08 Nov 2006 22:07:48 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gi0GX-0000sY-IY for speermint@ietf.org; Wed, 08 Nov 2006 22:07:48 -0500 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-4.tower-121.messagelabs.com!1163041664!11622312!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 6146 invoked from network); 9 Nov 2006 03:07:44 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-4.tower-121.messagelabs.com with SMTP; 9 Nov 2006 03:07:44 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kA937i3l018506; Wed, 8 Nov 2006 22:07:44 -0500 (EST) Received: from ACCLUST02EVS1.ugd.att.com (acst04.ugd.att.com [135.37.16.9]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kA937e7i018485; Wed, 8 Nov 2006 22:07:40 -0500 (EST) 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] Source-based routing Date: Wed, 8 Nov 2006 22:07:38 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A0E11404A@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280624F010@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing Thread-Index: AccDlHlStUMBnUcxT1aZYx9SfdE0cQAAJbBAAAWBvCA= From: "Pfautz, Penn L, GBLAM" To: "Reinaldo Penno" , "Uzelac, Adam" , X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 thought we did have a requirement that addressed at least part of this issue in draft-ietf-speermint-requirements-01.txt: o Variability of the Call Address Data: A terminating VSP/ASP or user SHOULD be able to indicate its domain ingress points (Signaling Path Border Element(s)) based on the identity of the originating VSP/ASP or user. The mechanisms recommended for the use and resolution of the call addressing data SHOULD allow for variability or customization of the response(s) depending on various elements, such as the identity of the originating or terminating user or user domain. Are you asking just to add geographic origin info to this? I see originating entity and location info helping to determine routing but it's not clear to me that this isn't a multi-stage (and maybe multi-protocol) process. And by location, are we talking originating user location or originating network element location? Penn -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 Sent: Wednesday, November 08, 2006 7:24 PM To: Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] Source-based routing Although I'm not a VSP I agree. At some point we discussed on this the fact that identity/geography/others should be taken into account when discovering/returning next-hop. That kind of faded way but seems a real problem to be tackled. Regards, Reinaldo > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 > Sent: Wednesday, November 08, 2006 4:18 PM > To: speermint@ietf.org > Subject: [Speermint] Source-based routing >=20 > Folks, >=20 > I would like to propose that we add to the list of=20 > requirements for SPEERMINT that any session routing proposal=20 > that is proposed take into account the ability to use some=20 > source criteria to return next-hop routes. I just re-read the=20 > requirements draft, and I did not see anything specifically=20 > addressing source-based routing.=20 >=20 > Speaking as a VSP, it's important that the ingress session=20 > border element that is returned to the originator of the=20 > request be based on, among other things, who's asking and=20 > from where. In practice, we do not return next-hop=20 > information irrespective if the request comes from Alice/Bob,=20 > or from China/Brazil. This may be a matter of local policy,=20 > but the tools and IDs that address session next-hop=20 > determination need to account for this. >=20 > -AU >=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 Wed Nov 08 23:34:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi1bk-0007xK-QV; Wed, 08 Nov 2006 23:33:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi1bi-0007xF-R9 for speermint@ietf.org; Wed, 08 Nov 2006 23:33:42 -0500 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi1bi-0002qO-Cj for speermint@ietf.org; Wed, 08 Nov 2006 23:33:42 -0500 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id CD1FD53F7; Wed, 8 Nov 2006 23:33:01 -0500 (EST) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 23:33:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speermint] Source-based routing Date: Wed, 8 Nov 2006 23:33:00 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing Thread-Index: AccDlHlStUMBnUcxT1aZYx9SfdE0cQAAJbBAAAWBvCAAA0M19Q== From: "Uzelac, Adam" To: "Pfautz, Penn L, GBLAM" , "Reinaldo Penno" , X-OriginalArrivalTime: 09 Nov 2006 04:33:01.0897 (UTC) FILETIME=[242A5B90:01C703B8] X-Spam-Score: 0.6 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f 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="===============0129005350==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============0129005350== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C703B8.2399F98C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C703B8.2399F98C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Penn, Thanks for setting me straight with regards to the requirements = citation. I believe that we indeed do need to add a provision in the = requirements to account for geography. That criteria would not pertain = to mobile scenarios, but in geographically static environments where the = request originates is pertinent. I am thinking originating network not = user, at this stage. -AU -----Original Message----- From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] Sent: Wed Nov 08 22:07:54 2006 To: Reinaldo Penno; Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] Source-based routing I thought we did have a requirement that addressed at least part of this issue in draft-ietf-speermint-requirements-01.txt: o Variability of the Call Address Data: A terminating VSP/ASP or user SHOULD be able to indicate its domain ingress points (Signaling Path Border Element(s)) based on the identity of the originating VSP/ASP or user. The mechanisms recommended for the use and resolution of the call addressing data SHOULD allow for variability or customization of the response(s) depending on various elements, such as the identity of the originating or terminating user or user domain. Are you asking just to add geographic origin info to this? I see originating entity and location info helping to determine routing but it's not clear to me that this isn't a multi-stage (and maybe multi-protocol) process. And by location, are we talking originating user location or originating network element location? Penn -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 Sent: Wednesday, November 08, 2006 7:24 PM To: Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] Source-based routing Although I'm not a VSP I agree. At some point we discussed on this the fact that identity/geography/others should be taken into account when discovering/returning next-hop. That kind of faded way but seems a real problem to be tackled. Regards, Reinaldo > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 > Sent: Wednesday, November 08, 2006 4:18 PM > To: speermint@ietf.org > Subject: [Speermint] Source-based routing >=20 > Folks, >=20 > I would like to propose that we add to the list of=20 > requirements for SPEERMINT that any session routing proposal=20 > that is proposed take into account the ability to use some=20 > source criteria to return next-hop routes. I just re-read the=20 > requirements draft, and I did not see anything specifically=20 > addressing source-based routing.=20 >=20 > Speaking as a VSP, it's important that the ingress session=20 > border element that is returned to the originator of the=20 > request be based on, among other things, who's asking and=20 > from where. In practice, we do not return next-hop=20 > information irrespective if the request comes from Alice/Bob,=20 > or from China/Brazil. This may be a matter of local policy,=20 > but the tools and IDs that address session next-hop=20 > determination need to account for this. >=20 > -AU >=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 ------_=_NextPart_001_01C703B8.2399F98C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Speermint] Source-based routing

Penn,

Thanks for setting me straight with regards to the requirements = citation.  I believe that we indeed do need to add a provision in = the requirements to account for geography.  That criteria would not = pertain to mobile scenarios, but in geographically static environments = where the request originates is pertinent.  I am thinking = originating network not user, at this stage.

-AU

 -----Original Message-----
From:   Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com]
Sent:   Wed Nov 08 22:07:54 2006
To:     Reinaldo Penno; Uzelac, Adam; = speermint@ietf.org
Subject:        RE: [Speermint] = Source-based routing

I thought we did have a requirement that addressed at least part of = this
issue in
draft-ietf-speermint-requirements-01.txt:

o  Variability of the Call Address Data:
      A terminating VSP/ASP or user SHOULD be = able to indicate its
      domain ingress points (Signaling Path = Border Element(s)) based on
      the identity of the originating VSP/ASP = or user.
      The mechanisms recommended for the use = and resolution of the call
      addressing data SHOULD allow for = variability or customization of
      the response(s) depending on various = elements, such as the
      identity of the originating or = terminating user or user domain.

Are you asking just to add geographic origin info to this?
I see originating entity and location info helping to determine = routing
but it's not clear to me that this isn't a multi-stage (and maybe
multi-protocol) process.
And by location, are we talking originating user location  or
originating network element location?

Penn
-----Original Message-----
From: Reinaldo Penno [mailto:rpenno@juniper.net]
Sent: Wednesday, November 08, 2006 7:24 PM
To: Uzelac, Adam; speermint@ietf.org
Subject: RE: [Speermint] Source-based routing

Although I'm not a VSP I agree. At some point we discussed on this = the
fact that identity/geography/others should be taken into account = when
discovering/returning next-hop. That kind of faded way but seems a = real
problem to be tackled.

Regards,

Reinaldo

> -----Original Message-----
> From: Uzelac, Adam [mailto:Adam.Uzelac@globalc= rossing.com]
> Sent: Wednesday, November 08, 2006 4:18 PM
> To: speermint@ietf.org
> Subject: [Speermint] Source-based routing
>
> Folks,
>
> I would like to propose that we add to the list of
> requirements for SPEERMINT that any session routing proposal
> that is proposed take into account the ability to use some
> source criteria to return next-hop routes. I just re-read the
> requirements draft, and I did not see anything specifically
> addressing source-based routing.
>
> Speaking as a VSP, it's important that the ingress session
> border element that is returned to the originator of the
> request be based on, among other things, who's asking and
> from where.  In practice, we do not return next-hop
> information irrespective if the request comes from Alice/Bob,
> or from China/Brazil.  This may be a matter of local = policy,
> but the tools and IDs that address session next-hop
> determination need to account for this.
>
> -AU
>
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ie= tf.org/mailman/listinfo/speermint
>

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ie= tf.org/mailman/listinfo/speermint

------_=_NextPart_001_01C703B8.2399F98C-- --===============0129005350== 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 --===============0129005350==-- From speermint-bounces@ietf.org Wed Nov 08 23:54:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi1vT-0000bo-7g; Wed, 08 Nov 2006 23:54:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi1vR-0000aW-Pk for speermint@ietf.org; Wed, 08 Nov 2006 23:54:05 -0500 Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi1mX-0004BT-HT for speermint@ietf.org; Wed, 08 Nov 2006 23:44:55 -0500 Received: from mail.nominum.com (mail.nominum.com [81.200.64.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id A9F2656823 for ; Wed, 8 Nov 2006 20:44:42 -0800 (PST) (envelope-from spouliotte@nominum.com) X-Spam-Status: No, hits=0.0 required=7.0 tests=AWL: -1.531,BAYES_99: 4.07,FORGED_RCVD_HELO: 0.135, HTML_30_40: 0.374,HTML_MESSAGE: 0.001,RCVD_NUMERIC_HELO: 1.5, CUSTOM_RULE_FROM: ALLOW,TOTAL_SCORE: 4.549 X-Spam-Level: Received: from 71.146.99.123 ([71.146.99.123]) by mail.nominum.com for speermint@ietf.org; Wed, 8 Nov 2006 20:44:41 -0800 To: speermint@ietf.org From: "Shawn Pouliotte" Subject: RE: [Speermint] Source-based routing In-Reply-To: FA035B2C8D1DB4438C54F1542A0EEBBC0413F905@EVS2.ams.gblxint.com Message-ID: <20061109044441.e0ee443a@mail.nominum.com> Date: Wed, 08 Nov 2006 20:44:41 -0800 X-User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 MIME-Version: 1.0 X-Spam-Score: 1.6 (+) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad 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="===============0193921761==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============0193921761== Content-Type: multipart/alternative; boundary="-----------b2e3be7dd5934357b1cacf3cd92bff39" This is a multi-part message in MIME format. -------------b2e3be7dd5934357b1cacf3cd92bff39 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey Adam, =20 Can you elaborate some on that=3F I understand the requirements for s= ource based routing and it makes sense but deriving geographic locality= is tough beyond mapping querier's IP address. If thats all you meant t= hen its all good and makes perfect sense to me. If its more than that p= lease elaborate.=20 =20 Thanks Shawn =5F=5F=5F=5F=5F =20 From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] To: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com], Reinaldo Penno [mail= to:rpenno@juniper.net], speermint@ietf.org Sent: Wed, 08 Nov 2006 20:33:00 -0800 Subject: RE: [Speermint] Source-based routing =20 Penn, =20 Thanks for setting me straight with regards to the requirements citatio= n. I believe that we indeed do need to add a provision in the requirem= ents to account for geography. That criteria would not pertain to mobi= le scenarios, but in geographically static environments where the reque= st originates is pertinent. I am thinking originating network not user= , at this stage. =20 -AU =20 -----Original Message----- From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] Sent: Wed Nov 08 22:07:54 2006 To: Reinaldo Penno; Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] Source-based routing =20 I thought we did have a requirement that addressed at least part of th= is issue in draft-ietf-speermint-requirements-01.txt: =20 o Variability of the Call Address Data: A terminating VSP/ASP or user SHOULD be able to indicate its domain ingress points (Signaling Path Border Element(s)) based o= n the identity of the originating VSP/ASP or user. The mechanisms recommended for the use and resolution of the cal= l addressing data SHOULD allow for variability or customization of the response(s) depending on various elements, such as the identity of the originating or terminating user or user domain. =20 Are you asking just to add geographic origin info to this=3F I see originating entity and location info helping to determine routin= g but it's not clear to me that this isn't a multi-stage (and maybe multi-protocol) process. And by location, are we talking originating user location or originating network element location=3F =20 Penn -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Wednesday, November 08, 2006 7:24 PM To: Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] Source-based routing =20 Although I'm not a VSP I agree. At some point we discussed on this the fact that identity/geography/others should be taken into account when discovering/returning next-hop. That kind of faded way but seems a rea= l problem to be tackled. =20 Regards, =20 Reinaldo =20 > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Wednesday, November 08, 2006 4:18 PM > To: speermint@ietf.org > Subject: [Speermint] Source-based routing > > Folks, > > I would like to propose that we add to the list of > requirements for SPEERMINT that any session routing proposal > that is proposed take into account the ability to use some > source criteria to return next-hop routes. I just re-read the > requirements draft, and I did not see anything specifically > addressing source-based routing. > > Speaking as a VSP, it's important that the ingress session > border element that is returned to the originator of the > request be based on, among other things, who's asking and > from where. In practice, we do not return next-hop > information irrespective if the request comes from Alice/Bob, > or from China/Brazil. This may be a matter of local policy, > but the tools and IDs that address session next-hop > determination need to account for this. > > -AU > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > =20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint =20 -------------b2e3be7dd5934357b1cacf3cd92bff39 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey Adam,

Can you elaborate some on that=3F I understand the requirements for source based routing and it makes sense but deriving geographic locality is tough beyond mapping querier's IP address. If thats all you meant then its all good and makes perfect sense to me. If its more than that please elaborate.

Thanks
Shawn
From: U= zelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]
To: Pfautz= , Penn L, GBLAM [mailto:ppfautz@att.com], Reinaldo Penno [mailto:rpenno@= juniper.net], speermint@ietf.org
Sent: Wed, 08 Nov 2006 20:33:= 00 -0800
Subject: RE: [Speermint] Source-based routing

Penn,

Thanks for setting me straight with regards to the requirements citation.  I believe that we indeed do need to add a provision in the requirements to account for geography.  That criteria would not pertain to mobile scenarios, but in geographically static environments where the request originates is pertinent.  I am thinking originating network not user, at this stage.

-AU

 -----Original Message-----
From:   Pfautz, Penn L, GBLAM [m= ailto:ppfautz@att.com]
Sent:   Wed Nov 08 22:07:54 2006
To:     Reinaldo Penno; Uzelac, Adam; speermint@ietf.org
Subject:        RE: [Speermint] Sourc= e-based routing

I thought we did have a requirement that addressed at least part of this=
issue in
draft-ietf-speermint-requirements-01.txt:

o  Variability of the Call Address Data:
      A terminating VSP/ASP or user SHOULD be a= ble to indicate its
      domain ingress points (Signaling Path Bor= der Element(s)) based on
      the identity of the originating VSP/ASP o= r user.
      The mechanisms recommended for the use an= d resolution of the call
      addressing data SHOULD allow for variabil= ity or customization of
      the response(s) depending on various elem= ents, such as the
      identity of the originating or terminatin= g user or user domain.

Are you asking just to add geographic origin info to this=3F
I see originating entity and location info helping to determine routing<= br> but it's not clear to me that this isn't a multi-stage (and maybe
multi-protocol) process.
And by location, are we talking originating user location  or
originating network element location=3F

Penn
-----Original Message-----
From: Reinaldo Penno [mailto:rpenn= o@juniper.net]
Sent: Wednesday, November 08, 2006 7:24 PM
To: Uzelac, Adam; speermint@ietf.o= rg
Subject: RE: [Speermint] Source-based routing

Although I'm not a VSP I agree. At some point we discussed on this the fact that identity/geography/others should be taken into account when discovering/returning next-hop. That kind of faded way but seems a real<= br> problem to be tackled.

Regards,

Reinaldo

> -----Original Message-----
> From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]
> Sent: Wednesday, November 08, 2006 4:18 PM
> To: speermint@ietf.org > Subject: [Speermint] Source-based routing
>
> Folks,
>
> I would like to propose that we add to the list of
> requirements for SPEERMINT that any session routing proposal
> that is proposed take into account the ability to use some
> source criteria to return next-hop routes. I just re-read the
> requirements draft, and I did not see anything specifically
> addressing source-based routing.
>
> Speaking as a VSP, it's important that the ingress session
> border element that is returned to the originator of the
> request be based on, among other things, who's asking and
> from where.  In practice, we do not return next-hop
> information irrespective if the request comes from Alice/Bob,
> or from China/Brazil.  This may be a matter of local policy, > but the tools and IDs that address session next-hop
> determination need to account for this.
>
> -AU
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F
> Speermint mailing list
> Speermint@ietf.org
> https:= //www1.ietf.org/mailman/listinfo/speermint
>

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Speermint mailing list
Speermint@ietf.org
https://www= 1.ietf.org/mailman/listinfo/speermint

-------------b2e3be7dd5934357b1cacf3cd92bff39-- --===============0193921761== 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 --===============0193921761==-- From speermint-bounces@ietf.org Thu Nov 09 00:50:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi2nZ-0002FW-UL; Thu, 09 Nov 2006 00:50:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi2nZ-0002FM-De for speermint@ietf.org; Thu, 09 Nov 2006 00:50:01 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gi2nX-0004l3-Sa for speermint@ietf.org; Thu, 09 Nov 2006 00:50:01 -0500 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] Source-based routing Date: Thu, 9 Nov 2006 06:46:53 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BE7@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing thread-index: AccDlHlStUMBnUcxT1aZYx9SfdE0cQAAJbBAAAWBvCAAA0M19QAClIFI References: From: "Stastny Richard" To: "Uzelac, Adam" , "Pfautz, Penn L, GBLAM" , "Reinaldo Penno" , 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 am thinking originating network not user, at this stage. =20 But it is the user what counts in L3 mediastream For signalling the location of the proxies is irrelevant =20 We have to be very carefull here and really exactly define the = requirements =20 Richard ________________________________ Von: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] Gesendet: Do 09.11.2006 05:33 An: Pfautz, Penn L, GBLAM; Reinaldo Penno; speermint@ietf.org Betreff: RE: [Speermint] Source-based routing Penn, Thanks for setting me straight with regards to the requirements = citation. I believe that we indeed do need to add a provision in the = requirements to account for geography. That criteria would not pertain = to mobile scenarios, but in geographically static environments where the = request originates is pertinent. I am thinking originating network not = user, at this stage. -AU -----Original Message----- From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] Sent: Wed Nov 08 22:07:54 2006 To: Reinaldo Penno; Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] Source-based routing I thought we did have a requirement that addressed at least part of this issue in draft-ietf-speermint-requirements-01.txt: o Variability of the Call Address Data: A terminating VSP/ASP or user SHOULD be able to indicate its domain ingress points (Signaling Path Border Element(s)) based on the identity of the originating VSP/ASP or user. The mechanisms recommended for the use and resolution of the call addressing data SHOULD allow for variability or customization of the response(s) depending on various elements, such as the identity of the originating or terminating user or user domain. Are you asking just to add geographic origin info to this? I see originating entity and location info helping to determine routing but it's not clear to me that this isn't a multi-stage (and maybe multi-protocol) process. And by location, are we talking originating user location or originating network element location? Penn -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Wednesday, November 08, 2006 7:24 PM To: Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] Source-based routing Although I'm not a VSP I agree. At some point we discussed on this the fact that identity/geography/others should be taken into account when discovering/returning next-hop. That kind of faded way but seems a real problem to be tackled. Regards, Reinaldo > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Wednesday, November 08, 2006 4:18 PM > To: speermint@ietf.org > Subject: [Speermint] Source-based routing > > Folks, > > I would like to propose that we add to the list of > requirements for SPEERMINT that any session routing proposal > that is proposed take into account the ability to use some > source criteria to return next-hop routes. I just re-read the > requirements draft, and I did not see anything specifically > addressing source-based routing. > > Speaking as a VSP, it's important that the ingress session > border element that is returned to the originator of the > request be based on, among other things, who's asking and > from where. In practice, we do not return next-hop > information irrespective if the request comes from Alice/Bob, > or from China/Brazil. This may be a matter of local policy, > but the tools and IDs that address session next-hop > determination need to account for this. > > -AU > > _______________________________________________ > 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 Nov 09 01:24:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi3KH-0002xw-0t; Thu, 09 Nov 2006 01:23:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi3KC-0002t7-CA for speermint@ietf.org; Thu, 09 Nov 2006 01:23:44 -0500 Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi3Hf-00010m-LP for speermint@ietf.org; Thu, 09 Nov 2006 01:21:10 -0500 Received: from mail.nominum.com (mail.nominum.com [81.200.64.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id E2BB456875 for ; Wed, 8 Nov 2006 22:20:56 -0800 (PST) (envelope-from spouliotte@nominum.com) X-Spam-Status: No, hits=0.0 required=7.0 tests=AWL: -1.325,BAYES_99: 4.07,FORGED_RCVD_HELO: 0.135, HTML_MESSAGE: 0.001,RCVD_NUMERIC_HELO: 1.5,CUSTOM_RULE_FROM: ALLOW, TOTAL_SCORE: 4.381 X-Spam-Level: Received: from 71.146.99.123 ([71.146.99.123]) by mail.nominum.com for speermint@ietf.org; Wed, 8 Nov 2006 22:20:53 -0800 To: speermint@ietf.org From: "Shawn Pouliotte" Subject: Re: [Speermint] Source-based routing In-Reply-To: 32755D354E6B65498C3BD9FD496C7D462C4BE7@oefeg-s04.oefeg.loc Message-ID: <20061109062053.8d0fe0a5@mail.nominum.com> Date: Wed, 08 Nov 2006 22:20:53 -0800 X-User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 MIME-Version: 1.0 X-Spam-Score: 2.1 (++) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 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="===============1106767981==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============1106767981== Content-Type: multipart/alternative; boundary="-----------c311362a84a76f25c9ae8280e5d140d4" This is a multi-part message in MIME format. -------------c311362a84a76f25c9ae8280e5d140d4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Richard, =20 Not sure I am completely clear on what you are saying... =20 Do you mean the ip address (if the originator is even IP) of the ca= lling party or the ip address of the querying entity=3F If you mean the = originating subscriber, can you explain why you would care=3F If this i= s a peering app, I would think you care who is presenting the call in = terms of determining what element to bring the call in on and not wheth= er the original caller was in Germany or Uganda. Likelyhood is you woul= d not even know depending on the way topology hiding was done. Unless I= am missing something, the traffic exchange agreements are based on whe= re the interconnect wants to terminate and not what the originating geo= graphy was of the originator.=20 =20 If I misunderstood you, please clarify. If not - and you do mean or= iginating subscriber ip address then please give a use case and elabora= te. =20 Thanks and sorry if I misunderstood Shawn =5F=5F=5F=5F=5F =20 From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] To: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com], Pfautz, Penn = L, GBLAM [mailto:ppfautz@att.com], Reinaldo Penno [mailto:rpenno@junip= er.net], speermint@ietf.org Sent: Wed, 08 Nov 2006 21:46:53 -0800 Subject: Re: [Speermint] Source-based routing >I am thinking originating network not user, at this stage. =20 But it is the user what counts in L3 mediastream For signalling the location of the proxies is irrelevant =20 We have to be very carefull here and really exactly define the require= ments =20 Richard =20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F =20 Von: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] Gesendet: Do 09.11.2006 05:33 An: Pfautz, Penn L, GBLAM; Reinaldo Penno; speermint@ietf.org Betreff: RE: [Speermint] Source-based routing =20 =20 =20 Penn, =20 Thanks for setting me straight with regards to the requirements citat= ion. I believe that we indeed do need to add a provision in the require= ments to account for geography. That criteria would not pertain to mobi= le scenarios, but in geographically static environments where the reque= st originates is pertinent. I am thinking originating network not user,= at this stage. =20 -AU =20 -----Original Message----- From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] Sent: Wed Nov 08 22:07:54 2006 To: Reinaldo Penno; Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] Source-based routing =20 I thought we did have a requirement that addressed at least part of th= is issue in draft-ietf-speermint-requirements-01.txt: =20 o Variability of the Call Address Data: A terminating VSP/ASP or user SHOULD be able to indicate its domain ingress points (Signaling Path Border Element(s)) based o= n the identity of the originating VSP/ASP or user. The mechanisms recommended for the use and resolution of the cal= l addressing data SHOULD allow for variability or customization of the response(s) depending on various elements, such as the identity of the originating or terminating user or user domain. =20 Are you asking just to add geographic origin info to this=3F I see originating entity and location info helping to determine routin= g but it's not clear to me that this isn't a multi-stage (and maybe multi-protocol) process. And by location, are we talking originating user location or originating network element location=3F =20 Penn -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Wednesday, November 08, 2006 7:24 PM To: Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] Source-based routing =20 Although I'm not a VSP I agree. At some point we discussed on this the fact that identity/geography/others should be taken into account when discovering/returning next-hop. That kind of faded way but seems a rea= l problem to be tackled. =20 Regards, =20 Reinaldo =20 > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Wednesday, November 08, 2006 4:18 PM > To: speermint@ietf.org > Subject: [Speermint] Source-based routing > > Folks, > > I would like to propose that we add to the list of > requirements for SPEERMINT that any session routing proposal > that is proposed take into account the ability to use some > source criteria to return next-hop routes. I just re-read the > requirements draft, and I did not see anything specifically > addressing source-based routing. > > Speaking as a VSP, it's important that the ingress session > border element that is returned to the originator of the > request be based on, among other things, who's asking and > from where. In practice, we do not return next-hop > information irrespective if the request comes from Alice/Bob, > or from China/Brazil. This may be a matter of local policy, > but the tools and IDs that address session next-hop > determination need to account for this. > > -AU > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > =20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint =20 =20 =20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint =20 -------------c311362a84a76f25c9ae8280e5d140d4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Richard,

Not sure I am completely clear on what you are saying...

Do you mean the ip address (if the originator is even IP) of the calling party or the ip address of the querying entity=3F If you mean th= e originating subscriber, can you explain why you would care=3F If this is a peering app, I would think you care who is presenting the call in terms of determining what element to bring the call in on and not whether the original caller was in Germany or Uganda. Likelyhood is you would not even know depending on the way topology hiding was done. Unless I am missing something, the traffic exchange agreements are based on where the interconnect wants to terminate and not what the originating geography was of the originator.

If I misunderstood you, please clarify. If not - and you do mean originating subscriber ip address then please give a use case and elaborate.

Thanks and sorry if I misunderstood
Shawn
From: Stast= ny Richard [mailto:Richard.Stastny@oefeg.at]
To: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com], Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com], Reinaldo Penno [mailto:rpenno@juniper.net], speermint@ietf.org
Sent: Wed, 08 = Nov 2006 21:46:53 -0800
Subject: Re: [Speermint] Source-based = routing

>I am thinking originating network not user, at this s= tage.

But it is the user what counts in L3 mediastream
For signalling the location of the proxies is irrelevant

We have to be very carefull here and really exactly define the requireme= nts

Richard

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F

Von: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]
Gesendet: Do 09.11.2006 05:33
An: Pfautz, Penn L, GBLAM; Reinaldo Penno; speermint@ietf.org
Betreff: RE: [Speermint] Source-based routing



Penn,

Thanks for setting me straight with regards to the requirements citation. I believe that we indeed do need to add a provision in the requirements to account for geography. That criteria would not pertain to mobile scenarios, but in geographically static environments where the request originates is pertinent. I am thinking originating network not user, at this stage.

-AU

-----Original Message-----
From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com]
Sent: Wed Nov 08 22:07:54 2006
To: Reinaldo Penno; Uzelac, Adam; speermint@ietf.org
Subject: RE: [Speermint] Source-based routing

I thought we did have a requirement that addressed at least part of this=
issue in
draft-ietf-speermint-requirements-01.txt:

o Variability of the Call Address Data:
A terminating VSP/ASP or user SHOULD be able to indicate its
domain ingress points (Signaling Path Border Element(s)) based on<= br> the identity of the originating VSP/ASP or user.
The mechanisms recommended for the use and resolution of the call<= br> addressing data SHOULD allow for variability or customization of the response(s) depending on various elements, such as the
identity of the originating or terminating user or user domain.
Are you asking just to add geographic origin info to this=3F
I see originating entity and location info helping to determine routing<= br> but it's not clear to me that this isn't a multi-stage (and maybe
multi-protocol) process.
And by location, are we talking originating user location or
originating network element location=3F

Penn
-----Original Message-----
From: Reinaldo Penno [mailto:rpenn= o@juniper.net]
Sent: Wednesday, November 08, 2006 7:24 PM
To: Uzelac, Adam; speermint@ietf.o= rg
Subject: RE: [Speermint] Source-based routing

Although I'm not a VSP I agree. At some point we discussed on this the fact that identity/geography/others should be taken into account when discovering/returning next-hop. That kind of faded way but seems a real<= br> problem to be tackled.

Regards,

Reinaldo

> -----Original Message-----
> From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]
> Sent: Wednesday, November 08, 2006 4:18 PM
> To: speermint@ietf.org > Subject: [Speermint] Source-based routing
>
> Folks,
>
> I would like to propose that we add to the list of
> requirements for SPEERMINT that any session routing proposal
> that is proposed take into account the ability to use some
> source criteria to return next-hop routes. I just re-read the
> requirements draft, and I did not see anything specifically
> addressing source-based routing.
>
> Speaking as a VSP, it's important that the ingress session
> border element that is returned to the originator of the
> request be based on, among other things, who's asking and
> from where. In practice, we do not return next-hop
> information irrespective if the request comes from Alice/Bob,
> or from China/Brazil. This may be a matter of local policy,
> but the tools and IDs that address session next-hop
> determination need to account for this.
>
> -AU
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint
>

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint
-------------c311362a84a76f25c9ae8280e5d140d4-- --===============1106767981== 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 --===============1106767981==-- From speermint-bounces@ietf.org Thu Nov 09 01:58:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi3rF-0004JV-H4; Thu, 09 Nov 2006 01:57:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi3rD-0004FH-W2 for speermint@ietf.org; Thu, 09 Nov 2006 01:57:52 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi3rC-0008Tr-LU for speermint@ietf.org; Thu, 09 Nov 2006 01:57:51 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 08 Nov 2006 22:54:59 -0800 X-IronPort-AV: i="4.09,402,1157353200"; d="scan'208"; a="606952942:sNHT38340888" 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] Source-based routing Date: Thu, 9 Nov 2006 01:57:46 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280624F03B@proton.jnpr.net> In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0E11404A@ACCLUST02EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing Thread-index: AccDlHlStUMBnUcxT1aZYx9SfdE0cQAAJbBAAAWBvCAACECioA== From: "Reinaldo Penno" To: "Pfautz, Penn L, GBLAM" , "Uzelac, Adam" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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 There is certainly a requirement, but no concrete method as to how to do it and what to take into consideration. I guess the problem statement is: For a certain call, how to I find the most appropriate egress/ingree peering point?=20 The parameters that make "this" call different from another call and how exactly you find the peering point are still not properly defined. > -----Original Message----- > From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com]=20 > Sent: Wednesday, November 08, 2006 7:08 PM > To: Reinaldo Penno; Uzelac, Adam; speermint@ietf.org > Subject: RE: [Speermint] Source-based routing >=20 > I thought we did have a requirement that addressed at least=20 > part of this issue in > draft-ietf-speermint-requirements-01.txt: >=20 > o Variability of the Call Address Data: > A terminating VSP/ASP or user SHOULD be able to indicate its > domain ingress points (Signaling Path Border=20 > Element(s)) based on > the identity of the originating VSP/ASP or user. > The mechanisms recommended for the use and resolution=20 > of the call > addressing data SHOULD allow for variability or customization of > the response(s) depending on various elements, such as the > identity of the originating or terminating user or user domain. >=20 > Are you asking just to add geographic origin info to this? > I see originating entity and location info helping to=20 > determine routing but it's not clear to me that this isn't a=20 > multi-stage (and maybe > multi-protocol) process. > And by location, are we talking originating user location or=20 > originating network element location? >=20 > Penn > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Wednesday, November 08, 2006 7:24 PM > To: Uzelac, Adam; speermint@ietf.org > Subject: RE: [Speermint] Source-based routing >=20 > Although I'm not a VSP I agree. At some point we discussed on=20 > this the fact that identity/geography/others should be taken=20 > into account when discovering/returning next-hop. That kind=20 > of faded way but seems a real problem to be tackled. >=20 > Regards, >=20 > Reinaldo >=20 > > -----Original Message----- > > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > > Sent: Wednesday, November 08, 2006 4:18 PM > > To: speermint@ietf.org > > Subject: [Speermint] Source-based routing > >=20 > > Folks, > >=20 > > I would like to propose that we add to the list of requirements for=20 > > SPEERMINT that any session routing proposal that is=20 > proposed take into=20 > > account the ability to use some source criteria to return next-hop=20 > > routes. I just re-read the requirements draft, and I did not see=20 > > anything specifically addressing source-based routing. > >=20 > > Speaking as a VSP, it's important that the ingress session border=20 > > element that is returned to the originator of the request=20 > be based on,=20 > > among other things, who's asking and from where. In=20 > practice, we do=20 > > not return next-hop information irrespective if the request=20 > comes from=20 > > Alice/Bob, or from China/Brazil. This may be a matter of local=20 > > policy, but the tools and IDs that address session next-hop=20 > > determination need to account for this. > >=20 > > -AU > >=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 Thu Nov 09 01:59:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi3sU-000529-Ly; Thu, 09 Nov 2006 01:59:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi3sT-000523-7i for speermint@ietf.org; Thu, 09 Nov 2006 01:59:09 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi3sR-0000CT-Oq for speermint@ietf.org; Thu, 09 Nov 2006 01:59:09 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 08 Nov 2006 22:56:15 -0800 X-IronPort-AV: i="4.09,402,1157353200"; d="scan'208"; a="606953344:sNHT43832632" 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] Source-based routing Date: Thu, 9 Nov 2006 01:59:04 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280624F03C@proton.jnpr.net> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BE7@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing Thread-index: AccDlHlStUMBnUcxT1aZYx9SfdE0cQAAJbBAAAWBvCAAA0M19QAClIFIAAJ8qHA= From: "Reinaldo Penno" To: "Stastny Richard" , "Uzelac, Adam" , "Pfautz, Penn L, GBLAM" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 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 Well put Richard. We keep putting media to the side. I think Adam did not do it on purpose, it is just force of habit (;-) since he has collpased peering points.=20 So, by call we mean signaling and media. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Wednesday, November 08, 2006 9:47 PM > To: Uzelac, Adam; Pfautz, Penn L, GBLAM; Reinaldo Penno;=20 > speermint@ietf.org > Subject: Re: [Speermint] Source-based routing >=20 > >I am thinking originating network not user, at this stage. > =20 > But it is the user what counts in L3 mediastream For=20 > signalling the location of the proxies is irrelevant > =20 > We have to be very carefull here and really exactly define=20 > the requirements > =20 > Richard >=20 > ________________________________ >=20 > Von: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Gesendet: Do 09.11.2006 05:33 > An: Pfautz, Penn L, GBLAM; Reinaldo Penno; speermint@ietf.org > Betreff: RE: [Speermint] Source-based routing >=20 >=20 >=20 > Penn, >=20 > Thanks for setting me straight with regards to the=20 > requirements citation. I believe that we indeed do need to=20 > add a provision in the requirements to account for geography.=20 > That criteria would not pertain to mobile scenarios, but in=20 > geographically static environments where the request=20 > originates is pertinent. I am thinking originating network=20 > not user, at this stage. >=20 > -AU >=20 > -----Original Message----- > From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] > Sent: Wed Nov 08 22:07:54 2006 > To: Reinaldo Penno; Uzelac, Adam; speermint@ietf.org > Subject: RE: [Speermint] Source-based routing >=20 > I thought we did have a requirement that addressed at least=20 > part of this issue in > draft-ietf-speermint-requirements-01.txt: >=20 > o Variability of the Call Address Data: > A terminating VSP/ASP or user SHOULD be able to indicate its > domain ingress points (Signaling Path Border=20 > Element(s)) based on > the identity of the originating VSP/ASP or user. > The mechanisms recommended for the use and resolution=20 > of the call > addressing data SHOULD allow for variability or customization of > the response(s) depending on various elements, such as the > identity of the originating or terminating user or user domain. >=20 > Are you asking just to add geographic origin info to this? > I see originating entity and location info helping to=20 > determine routing but it's not clear to me that this isn't a=20 > multi-stage (and maybe > multi-protocol) process. > And by location, are we talking originating user location or=20 > originating network element location? >=20 > Penn > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Wednesday, November 08, 2006 7:24 PM > To: Uzelac, Adam; speermint@ietf.org > Subject: RE: [Speermint] Source-based routing >=20 > Although I'm not a VSP I agree. At some point we discussed on=20 > this the fact that identity/geography/others should be taken=20 > into account when discovering/returning next-hop. That kind=20 > of faded way but seems a real problem to be tackled. >=20 > Regards, >=20 > Reinaldo >=20 > > -----Original Message----- > > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > > Sent: Wednesday, November 08, 2006 4:18 PM > > To: speermint@ietf.org > > Subject: [Speermint] Source-based routing > > > > Folks, > > > > I would like to propose that we add to the list of requirements for=20 > > SPEERMINT that any session routing proposal that is=20 > proposed take into=20 > > account the ability to use some source criteria to return next-hop=20 > > routes. I just re-read the requirements draft, and I did not see=20 > > anything specifically addressing source-based routing. > > > > Speaking as a VSP, it's important that the ingress session border=20 > > element that is returned to the originator of the request=20 > be based on,=20 > > among other things, who's asking and from where. In=20 > practice, we do=20 > > not return next-hop information irrespective if the request=20 > comes from=20 > > Alice/Bob, or from China/Brazil. This may be a matter of local=20 > > policy, but the tools and IDs that address session next-hop=20 > > determination need to account for this. > > > > -AU > > > > _______________________________________________ > > 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 Thu Nov 09 02:39:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi4Un-00071q-Na; Thu, 09 Nov 2006 02:38:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi4Um-00071M-0s for speermint@ietf.org; Thu, 09 Nov 2006 02:38:44 -0500 Received: from [2001:858:745:a0e4:20b:dbff:fe95:d83a] (helo=sil1.mah.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi4Uf-0006nt-T3 for speermint@ietf.org; Thu, 09 Nov 2006 02:38:44 -0500 Received: from [81.223.16.197] (helo=[192.168.1.240]) by sil1.mah.priv.at with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Gi4UG-0003D8-QX; Thu, 09 Nov 2006 08:38:13 +0100 Message-ID: <4552DABE.4060108@inode.at> Date: Thu, 09 Nov 2006 08:37:34 +0100 From: Michael Haberler User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Reinaldo Penno References: <9BD5D7887235424FA97DFC223CAE3C280624F03B@proton.jnpr.net> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280624F03B@proton.jnpr.net> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 81.223.16.197 X-SA-Exim-Mail-From: mah@inode.at X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on sil1.mah.priv.at X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.4 Subject: Re: [Speermint] Source-based routing X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on sil1.mah.priv.at) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: speermint@ietf.org, "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 Reinaldo Penno schrieb: > I guess the problem statement is: > > For a certain call, how to I find the most appropriate egress/ingree > peering point? > I'm not sure wether that was what Adam meant - need to clarify I see two interpretations: - topological optimization of next hop (IP adress, distance..) - a parameter into policy application - for resolution services which might give different answers to different originators -Michael _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Nov 09 02:47:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi4d7-0003aw-3O; Thu, 09 Nov 2006 02:47:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi4d5-0003af-5w for speermint@ietf.org; Thu, 09 Nov 2006 02:47:19 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gi4d4-0008EB-Gy for speermint@ietf.org; Thu, 09 Nov 2006 02:47:19 -0500 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] Source-based routing Date: Thu, 9 Nov 2006 08:46:30 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BE8@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing thread-index: AccDx45bxz8oOqJ9SRSdxl0d8HDdGwACiytM References: <20061109062053.8d0fe0a5@mail.nominum.com> From: "Stastny Richard" To: "Shawn Pouliotte" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f 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 What I wanted to say is that=20 =20 1. the whole issue is only relevant in the collapsed peering picture (figure 2 in draft-ietf-speermint-flows). In the basic peering picture the media goes directly from user to user =20 2.in figure 2 this makes sense, but also raises a lot of questions - who is taking the lead - the originating or terminating part (IMO the terminating part, but the decision has to be done be the originating part) - what are the criteria? distance function domain codec ... =20 Richard =20 =20 ________________________________ Von: Shawn Pouliotte [mailto:Shawn.Pouliotte@nominum.com] Gesendet: Do 09.11.2006 07:20 An: speermint@ietf.org Betreff: Re: [Speermint] Source-based routing Hi Richard, Not sure I am completely clear on what you are saying... Do you mean the ip address (if the originator is even IP) of the calling = party or the ip address of the querying entity? If you mean the = originating subscriber, can you explain why you would care? If this is a = peering app, I would think you care who is presenting the call in terms = of determining what element to bring the call in on and not whether the = original caller was in Germany or Uganda. Likelyhood is you would not = even know depending on the way topology hiding was done. Unless I am = missing something, the traffic exchange agreements are based on where = the interconnect wants to terminate and not what the originating = geography was of the originator.=20 If I misunderstood you, please clarify. If not - and you do mean = originating subscriber ip address then please give a use case and = elaborate. Thanks and sorry if I misunderstood Shawn=20 ________________________________ From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] To: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com], Pfautz, Penn = L, GBLAM [mailto:ppfautz@att.com], Reinaldo Penno = [mailto:rpenno@juniper.net], speermint@ietf.org Sent: Wed, 08 Nov 2006 21:46:53 -0800 Subject: Re: [Speermint] Source-based routing =09 >I am thinking originating network not user, at this stage. =09 But it is the user what counts in L3 mediastream For signalling the location of the proxies is irrelevant =09 We have to be very carefull here and really exactly define the = requirements =09 Richard =09 ________________________________ =09 Von: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] Gesendet: Do 09.11.2006 05:33 An: Pfautz, Penn L, GBLAM; Reinaldo Penno; speermint@ietf.org Betreff: RE: [Speermint] Source-based routing =09 =09 =09 Penn, =09 Thanks for setting me straight with regards to the requirements = citation. I believe that we indeed do need to add a provision in the = requirements to account for geography. That criteria would not pertain = to mobile scenarios, but in geographically static environments where the = request originates is pertinent. I am thinking originating network not = user, at this stage. =09 -AU =09 -----Original Message----- From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] Sent: Wed Nov 08 22:07:54 2006 To: Reinaldo Penno; Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] Source-based routing =09 I thought we did have a requirement that addressed at least part of = this issue in draft-ietf-speermint-requirements-01.txt: =09 o Variability of the Call Address Data: A terminating VSP/ASP or user SHOULD be able to indicate its domain ingress points (Signaling Path Border Element(s)) based on the identity of the originating VSP/ASP or user. The mechanisms recommended for the use and resolution of the call addressing data SHOULD allow for variability or customization of the response(s) depending on various elements, such as the identity of the originating or terminating user or user domain. =09 Are you asking just to add geographic origin info to this? I see originating entity and location info helping to determine routing but it's not clear to me that this isn't a multi-stage (and maybe multi-protocol) process. And by location, are we talking originating user location or originating network element location? =09 Penn -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Wednesday, November 08, 2006 7:24 PM To: Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] Source-based routing =09 Although I'm not a VSP I agree. At some point we discussed on this the fact that identity/geography/others should be taken into account when discovering/returning next-hop. That kind of faded way but seems a real problem to be tackled. =09 Regards, =09 Reinaldo =09 > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Wednesday, November 08, 2006 4:18 PM > To: speermint@ietf.org > Subject: [Speermint] Source-based routing > > Folks, > > I would like to propose that we add to the list of > requirements for SPEERMINT that any session routing proposal > that is proposed take into account the ability to use some > source criteria to return next-hop routes. I just re-read the > requirements draft, and I did not see anything specifically > addressing source-based routing. > > Speaking as a VSP, it's important that the ingress session > border element that is returned to the originator of the > request be based on, among other things, who's asking and > from where. In practice, we do not return next-hop > information irrespective if the request comes from Alice/Bob, > or from China/Brazil. This may be a matter of local policy, > but the tools and IDs that address session next-hop > determination need to account for this. > > -AU > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > =09 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint =09 =09 =09 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint =09 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Nov 09 04:05:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi5pj-0008QW-ML; Thu, 09 Nov 2006 04:04:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi5pi-0008QQ-Iu for speermint@ietf.org; Thu, 09 Nov 2006 04:04:26 -0500 Received: from bzq-25-94-44.cust.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi5ph-0002jQ-Ck for speermint@ietf.org; Thu, 09 Nov 2006 04:04:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speermint] Source-based routing Date: Thu, 9 Nov 2006 11:04:13 +0200 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A606550F40D2@isr-jlm-mail.Kayote.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing Thread-Index: AccDx45bxz8oOqJ9SRSdxl0d8HDdGwACiytMAAK/aUg= References: <20061109062053.8d0fe0a5@mail.nominum.com> <32755D354E6B65498C3BD9FD496C7D462C4BE8@oefeg-s04.oefeg.loc> From: "David Schwartz" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: a38f40f81e96f7c17c0b6f9de20b7099 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="===============1276876004==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============1276876004== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C703DE.06D6AEA6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C703DE.06D6AEA6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think the idea to define requirements for provisioning data format = will address this issue. For example, one piece of information that MUST = be provisioned is the resultant URI for a given E.164 number. While = typically this is a 1-1 relationship there is no reason for this to be = so as there can be many reasons why different requesting entities = resolve to different URIs. I will say that the reasons are not always = geographical. =20 I think therefore that this thread should wait for a draft on this. = Getting this draft out quickly is essential. I hope to publish to the = list in the next few days (weeks?) some information on what data we = require when uploading to our registries. =20 David =20 =20 ________________________________ From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thu 11/9/2006 9:46 AM To: Shawn Pouliotte; speermint@ietf.org Subject: Re: [Speermint] Source-based routing What I wanted to say is that 1. the whole issue is only relevant in the collapsed peering picture (figure 2 in draft-ietf-speermint-flows). In the basic peering picture the media goes directly from user to user 2.in figure 2 this makes sense, but also raises a lot of questions - who is taking the lead - the originating or terminating part (IMO the terminating part, but the decision has to be done be the originating part) - what are the criteria? distance function domain codec ... Richard ________________________________ Von: Shawn Pouliotte [mailto:Shawn.Pouliotte@nominum.com] Gesendet: Do 09.11.2006 07:20 An: speermint@ietf.org Betreff: Re: [Speermint] Source-based routing Hi Richard, Not sure I am completely clear on what you are saying... Do you mean the ip address (if the originator is even IP) of the calling = party or the ip address of the querying entity? If you mean the = originating subscriber, can you explain why you would care? If this is a = peering app, I would think you care who is presenting the call in terms = of determining what element to bring the call in on and not whether the = original caller was in Germany or Uganda. Likelyhood is you would not = even know depending on the way topology hiding was done. Unless I am = missing something, the traffic exchange agreements are based on where = the interconnect wants to terminate and not what the originating = geography was of the originator. If I misunderstood you, please clarify. If not - and you do mean = originating subscriber ip address then please give a use case and = elaborate. Thanks and sorry if I misunderstood Shawn ________________________________ From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] To: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com], = Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com], Reinaldo Penno = [mailto:rpenno@juniper.net], speermint@ietf.org Sent: Wed, 08 Nov 2006 21:46:53 -0800 Subject: Re: [Speermint] Source-based routing =20 >I am thinking originating network not user, at this stage. =20 But it is the user what counts in L3 mediastream For signalling the location of the proxies is irrelevant =20 We have to be very carefull here and really exactly define the = requirements =20 Richard =20 ________________________________ =20 Von: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] Gesendet: Do 09.11.2006 05:33 An: Pfautz, Penn L, GBLAM; Reinaldo Penno; speermint@ietf.org Betreff: RE: [Speermint] Source-based routing =20 =20 =20 Penn, =20 Thanks for setting me straight with regards to the requirements = citation. I believe that we indeed do need to add a provision in the = requirements to account for geography. That criteria would not pertain = to mobile scenarios, but in geographically static environments where the = request originates is pertinent. I am thinking originating network not = user, at this stage. =20 -AU =20 -----Original Message----- From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] Sent: Wed Nov 08 22:07:54 2006 To: Reinaldo Penno; Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] Source-based routing =20 I thought we did have a requirement that addressed at least part = of this issue in draft-ietf-speermint-requirements-01.txt: =20 o Variability of the Call Address Data: A terminating VSP/ASP or user SHOULD be able to indicate its domain ingress points (Signaling Path Border Element(s)) based = on the identity of the originating VSP/ASP or user. The mechanisms recommended for the use and resolution of the = call addressing data SHOULD allow for variability or customization of the response(s) depending on various elements, such as the identity of the originating or terminating user or user domain. =20 Are you asking just to add geographic origin info to this? I see originating entity and location info helping to determine = routing but it's not clear to me that this isn't a multi-stage (and = maybe multi-protocol) process. And by location, are we talking originating user location or originating network element location? =20 Penn -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Wednesday, November 08, 2006 7:24 PM To: Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] Source-based routing =20 Although I'm not a VSP I agree. At some point we discussed on = this the fact that identity/geography/others should be taken into account = when discovering/returning next-hop. That kind of faded way but seems = a real problem to be tackled. =20 Regards, =20 Reinaldo =20 > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Wednesday, November 08, 2006 4:18 PM > To: speermint@ietf.org > Subject: [Speermint] Source-based routing > > Folks, > > I would like to propose that we add to the list of > requirements for SPEERMINT that any session routing proposal > that is proposed take into account the ability to use some > source criteria to return next-hop routes. I just re-read the > requirements draft, and I did not see anything specifically > addressing source-based routing. > > Speaking as a VSP, it's important that the ingress session > border element that is returned to the originator of the > request be based on, among other things, who's asking and > from where. In practice, we do not return next-hop > information irrespective if the request comes from Alice/Bob, > or from China/Brazil. This may be a matter of local policy, > but the tools and IDs that address session next-hop > determination need to account for this. > > -AU > > _______________________________________________ > 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 _______________________________________________ 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 ------_=_NextPart_001_01C703DE.06D6AEA6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Speermint] Source-based routing=0A= =0A= =0A= =0A=
=0A=
I think the = idea to define requirements for provisioning data format will address = this issue. For example, one piece of information that MUST be = provisioned is the resultant URI for a given E.164 number. While = typically this is a 1-1 relationship there is no reason for this to be = so as there can be many reasons why different requesting entities = resolve to different URIs. I will say that the reasons are not always = geographical.
=0A=
 
=0A=
I think therefore that this = thread should wait for a draft on this. Getting this draft out quickly is essential. I hope to publish = to the list in the next few days (weeks?) some information on what data = we require when uploading to our registries.
=0A=
 
=0A=
David
=0A=
 
=0A=
 
=0A=

=0A=
=0A= From: Stastny Richard = [mailto:Richard.Stastny@oefeg.at]
Sent: Thu 11/9/2006 9:46 = AM
To: Shawn Pouliotte; speermint@ietf.org
Subject: = Re: [Speermint] Source-based routing

=0A=
=0A=

What I wanted to say is that

1. the whole issue = is only relevant in the collapsed peering picture
(figure 2 in = draft-ietf-speermint-flows). In the basic peering
picture the media = goes directly from user to user

2.in figure 2 this makes sense, = but also raises a lot of questions
- who is taking the lead - the = originating or terminating part
(IMO the terminating part, but the = decision has to be done be
the originating part)
- what are the = criteria?
distance
function
domain
codec
...

Richar= d



________________________________

Von: Shawn = Pouliotte [mailto:Shawn.Pouliotte@nominu= m.com]
Gesendet: Do 09.11.2006 07:20
An: = speermint@ietf.org
Betreff: Re: [Speermint] Source-based = routing


Hi Richard,

Not sure I am completely clear on = what you are saying...

Do you mean the ip address (if the = originator is even IP) of the calling party or the ip address of the = querying entity? If you mean the originating subscriber, can you explain = why you would care? If this is a peering app, I would think you care who = is presenting the call in terms of determining what element to bring the = call in on and not whether the original caller was in Germany or Uganda. = Likelyhood is you would not even know depending on the way topology = hiding was done. Unless I am missing something, the traffic exchange = agreements are based on where the interconnect wants to terminate and = not what the originating geography was of the originator.

If I = misunderstood you, please clarify. If not - and you do mean originating = subscriber ip address then please give a use case and = elaborate.

Thanks and sorry if I = misunderstood
Shawn

________________________________

&nb= sp;       From: Stastny Richard [mailto:Richard.Stastny@oefeg.at<= /A>]
        To: Uzelac, Adam [mailto:Adam.Uzelac@globalc= rossing.com], Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com], Reinaldo = Penno [mailto:rpenno@juniper.net], = speermint@ietf.org
        Sent: = Wed, 08 Nov 2006 21:46:53 = -0800
        Subject: Re: = [Speermint] Source-based = routing
       
  &nbs= p;     >I am thinking originating network not = user, at this = stage.
       
   = ;     But it is the user what counts in L3 = mediastream
        For signalling = the location of the proxies is = irrelevant
       
  &= nbsp;     We have to be very carefull here and = really exactly define the = requirements
       
  = ;      = Richard
       
  &nbs= p;     = ________________________________
      &= nbsp;
        Von: Uzelac, Adam = [mailto:Adam.Uzelac@globalc= rossing.com]
        Gesendet: = Do 09.11.2006 05:33
        An: = Pfautz, Penn L, GBLAM; Reinaldo Penno; = speermint@ietf.org
        = Betreff: RE: [Speermint] Source-based = routing
       
  &nbs= p;    
       <= BR>        = Penn,
       
   =      Thanks for setting me straight with regards to = the requirements citation. I believe that we indeed do need to add a = provision in the requirements to account for geography. That criteria = would not pertain to mobile scenarios, but in geographically static = environments where the request originates is pertinent. I am thinking = originating network not user, at this = stage.
       
   = ;     = -AU
       
   &n= bsp;    -----Original = Message-----
        From: Pfautz, = Penn L, GBLAM [mailto:ppfautz@att.com]
 &nbs= p;      Sent: Wed Nov 08 22:07:54 = 2006
        To: Reinaldo Penno; = Uzelac, Adam; = speermint@ietf.org
        = Subject: RE: [Speermint] Source-based = routing
       
  &nbs= p;     I thought we did have a requirement that = addressed at least part of = this
        issue = in
        = draft-ietf-speermint-requirements-01.txt:
    &nbs= p;  
        o = Variability of the Call Address = Data:
        A terminating = VSP/ASP or user SHOULD be able to indicate = its
        domain ingress points = (Signaling Path Border Element(s)) based = on
        the identity of the = originating VSP/ASP or = user.
        The mechanisms = recommended for the use and resolution of the = call
        addressing data = SHOULD allow for variability or customization = of
        the response(s) = depending on various elements, such as = the
        identity of the = originating or terminating user or user = domain.
       
  &nbs= p;     Are you asking just to add geographic origin = info to this?
        I see = originating entity and location info helping to determine = routing
        but it's not clear = to me that this isn't a multi-stage (and = maybe
        multi-protocol) = process.
        And by location, = are we talking originating user location = or
        originating network = element = location?
       
  &n= bsp;     = Penn
        -----Original = Message-----
        From: = Reinaldo Penno [mailto:rpenno@juniper.net]
&nbs= p;       Sent: Wednesday, November 08, = 2006 7:24 PM
        To: Uzelac, = Adam; speermint@ietf.org
        = Subject: RE: [Speermint] Source-based = routing
       
  &nbs= p;     Although I'm not a VSP I agree. At some point = we discussed on this the
        = fact that identity/geography/others should be taken into account = when
        discovering/returning = next-hop. That kind of faded way but seems a = real
        problem to be = tackled.
       
  &nb= sp;     = Regards,
       
  &nb= sp;     = Reinaldo
       
  &nb= sp;     > -----Original = Message-----
        > From: = Uzelac, Adam [mailto:Adam.Uzelac@globalc= rossing.com]
        > = Sent: Wednesday, November 08, 2006 4:18 = PM
        > To: = speermint@ietf.org
        > = Subject: [Speermint] Source-based = routing
        = >
        > = Folks,
        = >
        > I would like to = propose that we add to the list = of
        > requirements for = SPEERMINT that any session routing = proposal
        > that is = proposed take into account the ability to use = some
        > source criteria = to return next-hop routes. I just re-read = the
        > requirements = draft, and I did not see anything = specifically
        > = addressing source-based = routing.
        = >
        > Speaking as a = VSP, it's important that the ingress = session
        > border = element that is returned to the originator of = the
        > request be based = on, among other things, who's asking = and
        > from where. In = practice, we do not return = next-hop
        > information = irrespective if the request comes from = Alice/Bob,
        > or from = China/Brazil. This may be a matter of local = policy,
        > but the tools = and IDs that address session = next-hop
        > = determination need to account for = this.
        = >
        > = -AU
        = >
        > = _______________________________________________
   &nbs= p;    > Speermint mailing = list
        > = Speermint@ietf.org
        > https://www1.ie= tf.org/mailman/listinfo/speermint
     &n= bsp;  = >
       
   &= nbsp;    = _______________________________________________
   &nbs= p;    Speermint mailing = list
        = Speermint@ietf.org
        https://www1.ie= tf.org/mailman/listinfo/speermint
     &n= bsp; 
       
  &= nbsp;    
      &nbs= p; = _______________________________________________
   &nbs= p;    Speermint mailing = list
        = Speermint@ietf.org
        https://www1.ie= tf.org/mailman/listinfo/speermint
     &n= bsp; 


_______________________________________________
= Speermint mailing list
Speermint@ietf.org
https://www1.ie= tf.org/mailman/listinfo/speermint

------_=_NextPart_001_01C703DE.06D6AEA6-- --===============1276876004== 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 --===============1276876004==-- From speermint-bounces@ietf.org Thu Nov 09 14:28:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiFYa-000330-OX; Thu, 09 Nov 2006 14:27:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiFYZ-00031s-RP for speermint@ietf.org; Thu, 09 Nov 2006 14:27:23 -0500 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 1GiFW9-0001cs-1y for speermint@ietf.org; Thu, 09 Nov 2006 14:24:55 -0500 Received: from PMelampy2 [75.192.231.210] by acmepacket.com with ESMTP (SMTPD-9.10) id A04901E8; Thu, 09 Nov 2006 14:23:53 -0500 Message-Id: <200611091423547.SM01656@PMelampy2> From: "Patrick Melampy" To: "'Michael Haberler'" , "'Reinaldo Penno'" Subject: RE: [Speermint] Source-based routing Date: Thu, 9 Nov 2006 14:20:58 -0500 Message-ID: <00b101c70434$996545b0$800101df@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccD0mSmx/4W053JRWSZEtSRwjXmOAAHaing In-Reply-To: <4552DABE.4060108@inode.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: speermint@ietf.org, "'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 The real issue here affects signaling and media. It appears to me that the correct algorithm to use would be based on the offered addresses in the SDP, and which border signaling point is closest. The reasons for this are: 1.) The signaling originator may not be co-located with the source of media. This is often the case with Softswitch/Media Gateway sources of traffic. Its also like to be true with Softswitch Based endpoints (MGCP/NCS) where the call controller is centrally located, but the endpoints are widely distributed. 2.) The signaling crossing point that is closes to the source of the media provides a "best crossing point" for the media as well. Although I've resisted talking about the media --- its truly important. The location of the media crossing point, and the control of the media, are as important as any other aspect in peering. There are some that would suggest the signaling crossing points and media crossing points are un-related. But to subsequently setup, manage, and control the media with a middle box requires the same determination of the best media crossing point. The mechanisms for doing this "locate the best middle box" are weak at best. Some say use a policy server. However none of the policy server interfaces I have seen proposed by ETSI TISPAN, 3GPP, seem to include a "source ip address" in the request to help choose a destination ip address. While out of the scope of this working group, one should consider the utility of the following suggestion. I propose that the best signaling crossing point be determined based on the source of the media. This would provide for a defined crossing point that then could manage the media flows by association. -----Original Message----- From: Michael Haberler [mailto:mah@inode.at] Sent: Thursday, November 09, 2006 2:38 AM To: Reinaldo Penno Cc: speermint@ietf.org; Uzelac, Adam Subject: Re: [Speermint] Source-based routing Reinaldo Penno schrieb: > I guess the problem statement is: > > For a certain call, how to I findFrom speermint-bounces@ietf.org Thu Nov 09 14:28:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiFYa-000330-OX; Thu, 09 Nov 2006 14:27:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiFYZ-00031s-RP for speermint@ietf.org; Thu, 09 Nov 2006 14:27:23 -0500 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 1GiFW9-0001cs-1y for speermint@ietf.org; Thu, 09 Nov 2006 14:24:55 -0500 Received: from PMelampy2 [75.192.231.210] by acmepacket.com with ESMTP (SMTPD-9.10) id A04901E8; Thu, 09 Nov 2006 14:23:53 -0500 Message-Id: <200611091423547.SM01656@PMelampy2> From: "Patrick Melampy" To: "'Michael Haberler'" , "'Reinaldo Penno'" Subject: RE: [Speermint] Source-based routing Date: Thu, 9 Nov 2006 14:20:58 -0500 Message-ID: <00b101c70434$996545b0$800101df@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccD0mSmx/4W053JRWSZEtSRwjXmOAAHaing In-Reply-To: <4552DABE.4060108@inode.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: speermint@ietf.org, "'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 The real issue here affects signaling and media. It appears to me that the correct algorithm to use would be based on the offered addresses in the SDP, and which border signaling point is closest. The reasons for this are: 1.) The signaling originator may not be co-located with the source of media. This is often the case with Softswitch/Media Gateway sources of traffic. Its also like to be true with Softswitch Based endpoints (MGCP/NCS) where the call controller is centrally located, but the endpoints are widely distributed. 2.) The signaling crossing point that is closes to the source of the media provides a "best crossing point" for the media as well. Although I've resisted talking about the media --- its truly important. The location of the media crossing point, and the control of the media, are as important as any other aspect in peering. There are some that would suggest the signaling crossing points and media crossing points are un-related. But to subsequently setup, manage, and control the media with a middle box requires the same determination of the best media crossing point. The mechanisms for doing this "locate the best middle box" are weak at best. Some say use a policy server. However none of the policy server interfaces I have seen proposed by ETSI TISPAN, 3GPP, seem to include a "source ip address" in the request to help choose a destination ip address. While out of the scope of this working group, one should consider the utility of the following suggestion. I propose that the best signaling crossing point be determined based on the source of the media. This would provide for a defined crossing point that then could manage the media flows by association. -----Original Message----- From: Michael Haberler [mailto:mah@inode.at] Sent: Thursday, November 09, 2006 2:38 AM To: Reinaldo Penno Cc: speermint@ietf.org; Uzelac, Adam Subject: Re: [Speermint] Source-based routing Reinaldo Penno schrieb: > I guess the problem statement is: > > For a certain call, how to I find the most appropriate egress/ingree > peering point? > I'm not sure wether that was what Adam meant - need to clarify I see two interpretations: - topological optimization of next hop (IP adress, distance..) - a parameter into policy application - for resolution services which might give different answers to different originators -Michael _______________________________________________ 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 Nov 09 14:28:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiFYr-0003b8-Rq; Thu, 09 Nov 2006 14:27:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiFYp-0003Zu-SA for speermint@ietf.org; Thu, 09 Nov 2006 14:27:39 -0500 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiFSp-00017A-LG for speermint@ietf.org; Thu, 09 Nov 2006 14:21:30 -0500 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 3FB1434B5; Thu, 9 Nov 2006 14:20:57 -0500 (EST) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 14:20: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] Source-based routing Date: Thu, 9 Nov 2006 14:20:55 -0500 Message-ID: In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BE7@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing Thread-Index: AccDlHlStUMBnUcxT1aZYx9SfdE0cQAAJbBAAAWBvCAAA0M19QAClIFIABtRzHA= From: "Uzelac, Adam" To: "Stastny Richard" , "Pfautz, Penn L, GBLAM" , "Reinaldo Penno" , X-OriginalArrivalTime: 09 Nov 2006 19:20:57.0176 (UTC) FILETIME=[2EB4CD80:01C70434] X-Spam-Score: 0.1 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a 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 - I absolutely understand the use case that you are referring to - it is the roaming user that is registered to a "home" proxy from afar. It's positively true that we can't assume anything about the user's location based on any assumed location of the proxy that initiates requests on behalf of that user. That point might need to be included in the requirements, but it should go without saying. =20 I think that the requirement as it reads in the current requirements draft needs a little noodling: First sentence currently reads: A terminating VSP/ASP or user SHOULD be able to indicate its domain ingress points (Signaling Path Border Element(s)) based on the identity of the originating VSP/ASP or user. Proposed change: The mechanisms recommended for the use and resolution of the call addressing data SHOULD allow for variability or customization of the response(s) depending on various elem the most appropriate egress/ingree > peering point? > I'm not sure wether that was what Adam meant - need to clarify I see two interpretations: - topological optimization of next hop (IP adress, distance..) - a parameter into policy application - for resolution services which might give different answers to different originators -Michael _______________________________________________ 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 Nov 09 14:28:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiFYr-0003b8-Rq; Thu, 09 Nov 2006 14:27:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiFYp-0003Zu-SA for speermint@ietf.org; Thu, 09 Nov 2006 14:27:39 -0500 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiFSp-00017A-LG for speermint@ietf.org; Thu, 09 Nov 2006 14:21:30 -0500 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 3FB1434B5; Thu, 9 Nov 2006 14:20:57 -0500 (EST) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 14:20: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] Source-based routing Date: Thu, 9 Nov 2006 14:20:55 -0500 Message-ID: In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BE7@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing Thread-Index: AccDlHlStUMBnUcxT1aZYx9SfdE0cQAAJbBAAAWBvCAAA0M19QAClIFIABtRzHA= From: "Uzelac, Adam" To: "Stastny Richard" , "Pfautz, Penn L, GBLAM" , "Reinaldo Penno" , X-OriginalArrivalTime: 09 Nov 2006 19:20:57.0176 (UTC) FILETIME=[2EB4CD80:01C70434] X-Spam-Score: 0.1 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a 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 - I absolutely understand the use case that you are referring to - it is the roaming user that is registered to a "home" proxy from afar. It's positively true that we can't assume anything about the user's location based on any assumed location of the proxy that initiates requests on behalf of that user. That point might need to be included in the requirements, but it should go without saying. =20 I think that the requirement as it reads in the current requirements draft needs a little noodling: First sentence currently reads: A terminating VSP/ASP or user SHOULD be able to indicate its domain ingress points (Signaling Path Border Element(s)) based on the identity of the originating VSP/ASP or user. Proposed change: The mechanisms recommended for the use and resolution of the call addressing data SHOULD allow for variability or customization of the response(s) depending on various elements, such as the source and/or identity of the originating or any relevant terminating information of the user or user domain.=20 To address a comment Penn makes - I don't believe that this suggested change necessitates "multi-stage (and maybe multi-protocol) process". -AU -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Wednesday, November 08, 2006 9:47 PM To: Uzelac, Adam; Pfautz, Penn L, GBLAM; Reinaldo Penno; speermint@ietf.org Subject: Re: [Speermint] Source-based routing >I am thinking originating network not user, at this stage. =20 But it is the user what counts in L3 mediastream For signalling the location of the proxies is irrelevant =20 We have to be very carefull here and really exactly define the requirements =20 Richard ________________________________ Von: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] Gesendet: Do 09.11.2006 05:33 An: Pfautz, Penn L, GBLAM; Reinaldo Penno; speermint@ietf.org Betreff: RE: [Speermint] Source-based routing Penn, Thanks for setting me straight with regards to the requirements citation. I believe that we indeed do need to add a provision in the requirements to account for geography. That criteria would not pertain to mobile scenarios, but in geographically static environments where the request originates is pertinent. I am thinking originating network not user, at this stage. -AU -----Original Message----- From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] Sent: Wed Nov 08 22:07:54 2006 To: Reinaldo Penno; Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] Source-based routing I thought we did have a requirement that addressed at least part of this issue in draft-ietf-speermint-requirements-01.txt: o Variability of the Call Address Data: A terminating VSP/ASP or user SHOULD be able to indicate its domain ingress points (Signaling Path Border Element(s)) based on the identity of the originating VSP/ASP or user. The mechanisms recommended for the use and resolution of the call addressing data SHOULD allow for variability or customization of the response(s) depending on various elements, such as the identity of the originating or terminating user or user domain. Are you asking just to add geographic origin info to this? I see originating entity and location info helping to determine routing but it's not clear to me that this isn't a multi-stage (and maybe multi-protocol) process. And by location, are we talking originating user location or originating network element location? Penn -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Wednesday, November 08, 2006 7:24 PM To: Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] Source-based routing Although I'm not a VSP I agree. At some point we discussed on this the fact that identity/geography/others should be taken into account when discovering/returning next-hop. That kind of faded way but seems a real problem to be tackled. Regards, Reinaldo > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Wednesday, November 08, 2006 4:18 PM > To: speermint@ietf.org > Subject: [Speermint] Source-based routing > > Folks, > > I would like to propose that we add to the list of requirements for=20 > SPEERMINT that any session routing proposal that is proposed take into > account the ability to use some source criteria to return next-hop=20 > routes. I just re-read the requirements draft, and I did not see=20 > anything specifically addressing source-based routing. > > Speaking as a VSP, it's important that the ingress session border=20 > element that is returned to the originator of the request be based on, > among other things, who's asking and from where. In practice, we do=20 > not return next-hop information irrespective if the request comes from > Alice/Bob, or from China/Brazil. This may be a matter of local=20 > policy, but the tools and IDs that address session next-hop=20 > determination need to account for thents, such as the source and/or identity of the originating or any relevant terminating information of the user or user domain.=20 To address a comment Penn makes - I don't believe that this suggested change necessitates "multi-stage (and maybe multi-protocol) process". -AU -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Wednesday, November 08, 2006 9:47 PM To: Uzelac, Adam; Pfautz, Penn L, GBLAM; Reinaldo Penno; speermint@ietf.org Subject: Re: [Speermint] Source-based routing >I am thinking originating network not user, at this stage. =20 But it is the user what counts in L3 mediastream For signalling the location of the proxies is irrelevant =20 We have to be very carefull here and really exactly define the requirements =20 Richard ________________________________ Von: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] Gesendet: Do 09.11.2006 05:33 An: Pfautz, Penn L, GBLAM; Reinaldo Penno; speermint@ietf.org Betreff: RE: [Speermint] Source-based routing Penn, Thanks for setting me straight with regards to the requirements citation. I believe that we indeed do need to add a provision in the requirements to account for geography. That criteria would not pertain to mobile scenarios, but in geographically static environments where the request originates is pertinent. I am thinking originating network not user, at this stage. -AU -----Original Message----- From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] Sent: Wed Nov 08 22:07:54 2006 To: Reinaldo Penno; Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] Source-based routing I thought we did have a requirement that addressed at least part of this issue in draft-ietf-speermint-requirements-01.txt: o Variability of the Call Address Data: A terminating VSP/ASP or user SHOULD be able to indicate its domain ingress points (Signaling Path Border Element(s)) based on the identity of the originating VSP/ASP or user. The mechanisms recommended for the use and resolution of the call addressing data SHOULD allow for variability or customization of the response(s) depending on various elements, such as the identity of the originating or terminating user or user domain. Are you asking just to add geographic origin info to this? I see originating entity and location info helping to determine routing but it's not clear to me that this isn't a multi-stage (and maybe multi-protocol) process. And by location, are we talking originating user location or originating network element location? Penn -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Wednesday, November 08, 2006 7:24 PM To: Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] Source-based routing Although I'm not a VSP I agree. At some point we discussed on this the fact that identity/geography/others should be taken into account when discovering/returning next-hop. That kind of faded way but seems a real problem to be tackled. Regards, Reinaldo > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Wednesday, November 08, 2006 4:18 PM > To: speermint@ietf.org > Subject: [Speermint] Source-based routing > > Folks, > > I would like to propose that we add to the list of requirements for=20 > SPEERMINT that any session routing proposal that is proposed take into > account the ability to use some source criteria to return next-hop=20 > routes. I just re-read the requirements draft, and I did not see=20 > anything specifically addressing source-based routing. > > Speaking as a VSP, it's important that the ingress session border=20 > element that is returned to the originator of the request be based on, > among other things, who's asking and from where. In practice, we do=20 > not return next-hop information irrespective if the request comes from > Alice/Bob, or from China/Brazil. This may be a matter of local=20 > policy, but the tools and IDs that address session next-hop=20 > determination need to account for this. > > -AU > > _______________________________________________ > 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 is. > > -AU > > _______________________________________________ > 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 Nov 09 14:34:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiFfX-0002x7-7r; Thu, 09 Nov 2006 14:34:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiFfW-0002x2-Ok for speermint@ietf.org; Thu, 09 Nov 2006 14:34:34 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GiFfU-00045g-GB for speermint@ietf.org; Thu, 09 Nov 2006 14:34:34 -0500 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-3.tower-121.messagelabs.com!1163100871!15517160!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 26046 invoked from network); 9 Nov 2006 19:34:31 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-3.tower-121.messagelabs.com with SMTP; 9 Nov 2006 19:34:31 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kA9JYU1c029255; Thu, 9 Nov 2006 14:34:31 -0500 (EST) Received: from ACCLUST02EVS1.ugd.att.com (acst04.ugd.att.com [135.37.16.9]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kA9JYJ8W029186; Thu, 9 Nov 2006 14:34:19 -0500 (EST) 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] Source-based routing Date: Thu, 9 Nov 2006 14:34:17 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A0E1146EB@ACCLUST02EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing Thread-Index: AccDlHlStUMBnUcxT1aZYx9SfdE0cQAAJbBAAAWBvCAAA0M19QAClIFIABtRzHAAAX2BYA== From: "Pfautz, Penn L, GBLAM" To: "Uzelac, Adam" , "Stastny Richard" , "Reinaldo Penno" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 Adam: Re the point below, I'm not sure that at least multi-stage isn't necessary but maybe it's a matter of semantics. I look to, for example, an ENUM query returning a URI which different entities might resolve differently. Penn -----Original Message----- From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 Sent: Thursday, November 09, 2006 2:21 PM To: Stastny Richard; Pfautz, Penn L, GBLAM; Reinaldo Penno; speermint@ietf.org Subject: RE: [Speermint] Source-based routing .... To address a comment Penn makes - I don't believe that this suggested change necessitates "multi-stage (and maybe multi-protocol) process". -AU _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Nov 09 14:56:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiG0X-0000Ub-56; Thu, 09 Nov 2006 14:56:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiG0V-0000UW-Vc for speermint@ietf.org; Thu, 09 Nov 2006 14:56:15 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiG0U-00073h-JC for speermint@ietf.org; Thu, 09 Nov 2006 14:56:15 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 09 Nov 2006 11:53:23 -0800 X-IronPort-AV: i="4.09,406,1157353200"; d="scan'208"; a="607239188:sNHT37673828" 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] Source-based routing Date: Thu, 9 Nov 2006 14:56:12 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280624F1EA@proton.jnpr.net> In-Reply-To: <00b101c70434$996545b0$800101df@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing Thread-index: AccD0mSmx/4W053JRWSZEtSRwjXmOAAHaingABHXpJA= From: "Reinaldo Penno" To: "Patrick Melampy" , "Michael Haberler" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: speermint@ietf.org, "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 As I side note I mentioned in the IETF meeting that we keep pushing media aside and only talking about signaling but what mostly matters in terms of user experience is the media. So, I agree with you that media is important. About your suggestion below, that's a nice insight, but it is still not clear to me how from the source IP address the proxy finds the notion of "distance". Of course the first peering proxy that receives the signaling can look at number of Vias or TTL or others. But how would this proxy find out the distance between the endpoint and other peering proxies in order to send a correct 302, for instance?=20 So, the "default" peering proxy can try to find that out (even if consulting some external DB) or the endpoint could try itself. The endpoint could send OPTION messages with increasing Max-Forwards to a coupld of proxies, or some other funky method. Thanks, Reinaldo =20 > -----Original Message----- > From: Patrick Melampy [mailto:PMelampy@acmepacket.com]=20 > Sent: Thursday, November 09, 2006 11:21 AM > To: 'Michael Haberler'; Reinaldo Penno > Cc: speermint@ietf.org; 'Uzelac, Adam' > Subject: RE: [Speermint] Source-based routing >=20 > The real issue here affects signaling and media. It appears=20 > to me that the correct algorithm to use would be based on the=20 > offered addresses in the SDP, and which border signaling=20 > point is closest. The reasons for this are: >=20 > 1.) The signaling originator may not be co-located with the=20 > source of media. > This is often the case with Softswitch/Media Gateway sources=20 > of traffic. Its also like to be true with Softswitch Based=20 > endpoints (MGCP/NCS) where the call controller is centrally=20 > located, but the endpoints are widely distributed. >=20 > 2.) The signaling crossing point that is closes to the source=20 > of the media provides a "best crossing point" for the media as well. >=20 > Although I've resisted talking about the media --- its truly=20 > important. The location of the media crossing point, and the=20 > control of the media, are as important as any other aspect in=20 > peering.=20 >=20 > There are some that would suggest the signaling crossing=20 > points and media crossing points are un-related. But to=20 > subsequently setup, manage, and control the media with a=20 > middle box requires the same determination of the best media=20 > crossing point. The mechanisms for doing this "locate the=20 > best middle box" are weak at best. Some say use a policy=20 > server. However none of the policy server interfaces I have=20 > seen proposed by ETSI TISPAN, 3GPP, seem to include a "source=20 > ip address" in the request to help choose a destination ip=20 > address. While out of the scope of this working group, one=20 > should consider the utility of the following suggestion. >=20 > I propose that the best signaling crossing point be=20 > determined based on the source of the media. This would=20 > provide for a defined crossing point that then could manage=20 > the media flows by association. >=20 > -----Original Message----- > From: Michael Haberler [mailto:mah@inode.at] > Sent: Thursday, November 09, 2006 2:38 AM > To: Reinaldo Penno > Cc: speermint@ietf.org; Uzelac, Adam > Subject: Re: [Speermint] Source-based routing >=20 > Reinaldo Penno schrieb: > > I guess the problem statement is: > > > > For a certain call, how to I find the most appropriate=20 > egress/ingree=20 > > peering point? > > =20 >=20 > I'm not sure wether that was what Adam meant - need to clarify >=20 > I see two interpretations: > - topological optimization of next hop (IP adress, distance..) > - a parameter into policy application - for resolution=20 > services which might give different answers to different originators >=20 >=20 >=20 > -Michael >=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 Nov 09 15:07:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiGAm-0004yQ-Jv; Thu, 09 Nov 2006 15:06:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiGAl-0004yL-HY for speermint@ietf.org; Thu, 09 Nov 2006 15:06:51 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GiGAj-0008Du-SB for speermint@ietf.org; Thu, 09 Nov 2006 15:06:51 -0500 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] Source-based routing Date: Thu, 9 Nov 2006 21:05:07 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BF4@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing thread-index: AccDlHlStUMBnUcxT1aZYx9SfdE0cQAAJbBAAAWBvCAAA0M19QAClIFIABtRzHAAAqdaYA== References: From: "Stastny Richard" To: "Uzelac, Adam" , "Pfautz, Penn L, GBLAM" , "Reinaldo Penno" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 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 >Proposed change: The mechanisms >recommended for the use and resolution of the call addressing data >SHOULD allow for variability or customization of the response(s) >depending on various elements, such as the source and/or identity of = the >originating or any relevant terminating information of the user or user >domain. Sounds good =20 Richard ________________________________ Von: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] Gesendet: Do 09.11.2006 20:20 An: Stastny Richard; Pfautz, Penn L, GBLAM; Reinaldo Penno; = speermint@ietf.org Betreff: RE: [Speermint] Source-based routing Richard - I absolutely understand the use case that you are referring to - it is the roaming user that is registered to a "home" proxy from afar. It's positively true that we can't assume anything about the user's location based on any assumed location of the proxy that initiates requests on behalf of that user. That point might need to be included in the requirements, but it should go without saying.=20 I think that the requirement as it reads in the current requirements draft needs a little noodling: First sentence currently reads: A terminating VSP/ASP or user SHOULD be able to indicate its domain ingress points (Signaling Path Border Element(s)) based on the identity of the originating VSP/ASP or user. Proposed change: The mechanisms recommended for the use and resolution of the call addressing data SHOULD allow for variability or customization of the response(s) depending on various elements, such as the source and/or identity of the originating or any relevant terminating information of the user or user domain. To address a comment Penn makes - I don't believe that this suggested change necessitates "multi-stage (and maybe multi-protocol) process". -AU -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Wednesday, November 08, 2006 9:47 PM To: Uzelac, Adam; Pfautz, Penn L, GBLAM; Reinaldo Penno; speermint@ietf.org Subject: Re: [Speermint] Source-based routing >I am thinking originating network not user, at this stage. But it is the user what counts in L3 mediastream For signalling the location of the proxies is irrelevant We have to be very carefull here and really exactly define the requirements Richard ________________________________ Von: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] Gesendet: Do 09.11.2006 05:33 An: Pfautz, Penn L, GBLAM; Reinaldo Penno; speermint@ietf.org Betreff: RE: [Speermint] Source-based routing Penn, Thanks for setting me straight with regards to the requirements citation. I believe that we indeed do need to add a provision in the requirements to account for geography. That criteria would not pertain to mobile scenarios, but in geographically static environments where the request originates is pertinent. I am thinking originating network not user, at this stage. -AU -----Original Message----- From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] Sent: Wed Nov 08 22:07:54 2006 To: Reinaldo Penno; Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] Source-based routing I thought we did have a requirement that addressed at least part of this issue in draft-ietf-speermint-requirements-01.txt: o Variability of the Call Address Data: A terminating VSP/ASP or user SHOULD be able to indicate its domain ingress points (Signaling Path Border Element(s)) based on the identity of the originating VSP/ASP or user. The mechanisms recommended for the use and resolution of the call addressing data SHOULD allow for variability or customization of the response(s) depending on various elements, such as the identity of the originating or terminating user or user domain. Are you asking just to add geographic origin info to this? I see originating entity and location info helping to determine routing but it's not clear to me that this isn't a multi-stage (and maybe multi-protocol) process. And by location, are we talking originating user location or originating network element location? Penn -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Wednesday, November 08, 2006 7:24 PM To: Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] Source-based routing Although I'm not a VSP I agree. At some point we discussed on this the fact that identity/geography/others should be taken into account when discovering/returning next-hop. That kind of faded way but seems a real problem to be tackled. Regards, Reinaldo > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Wednesday, November 08, 2006 4:18 PM > To: speermint@ietf.org > Subject: [Speermint] Source-based routing > > Folks, > > I would like to propose that we add to the list of requirements for > SPEERMINT that any session routing proposal that is proposed take into > account the ability to use some source criteria to return next-hop > routes. I just re-read the requirements draft, and I did not see > anything specifically addressing source-based routing. > > Speaking as a VSP, it's important that the ingress session border > element that is returned to the originator of the request be based on, > among other things, who's asking and from where. In practice, we do > not return next-hop information irrespective if the request comes from > Alice/Bob, or from China/Brazil. This may be a matter of local > policy, but the tools and IDs that address session next-hop > determination need to account for this. > > -AU > > _______________________________________________ > 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 Nov 09 15:12:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiGFY-0008TX-4O; Thu, 09 Nov 2006 15:11:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiGFW-0008R2-R2 for speermint@ietf.org; Thu, 09 Nov 2006 15:11:46 -0500 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiGFS-0000lU-NF for speermint@ietf.org; Thu, 09 Nov 2006 15:11:46 -0500 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 6BA972D760; Thu, 9 Nov 2006 15:11:42 -0500 (EST) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 15:11:29 -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] Source-based routing Date: Thu, 9 Nov 2006 15:11:19 -0500 Message-ID: In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280624F1EA@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing Thread-Index: AccD0mSmx/4W053JRWSZEtSRwjXmOAAHaingABHXpJAAALFfsA== From: "Uzelac, Adam" To: "Reinaldo Penno" , "Patrick Melampy" , "Michael Haberler" X-OriginalArrivalTime: 09 Nov 2006 20:11:29.0922 (UTC) FILETIME=[3E5D1E20:01C7043B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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 Is there consensus around the notion that media considerations are in scope of SPEERMINT? It's not always the case, but it should be a consideration when determining next-hops route responses to a location function look-up. I would like to point out that this becomes very difficult in ENUM/DNS next-hop determinations. Hence the existence of the INVITE/3XX next-hop determination method. -AU PS - please read "media considerations" as _NOT_ meaning exclusively CODECs.=20 -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 Sent: Thursday, November 09, 2006 11:56 AM To: Patrick Melampy; Michael Haberler Cc: speermint@ietf.org; Uzelac, Adam Subject: RE: [Speermint] Source-based routing As I side note I mentioned in the IETF meeting that we keep pushing media aside and only talking about signaling but what mostly matters in terms of user experience is the media. So, I agree with you that media is important. About your suggestion below, that's a nice insight, but it is still not clear to me how from the source IP address the proxy finds the notion of "distance". Of course the first peering proxy that receives the signaling can look at number of Vias or TTL or others. But how would this proxy find out the distance between the endpoint and other peering proxies in order to send a correct 302, for instance?=20 So, the "default" peering proxy can try to find that out (even if consulting some external DB) or the endpoint could try itself. The endpoint could send OPTION messages with increasing Max-Forwards to a coupld of proxies, or some other funky method. Thanks, Reinaldo =20 > -----Original Message----- > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Sent: Thursday, November 09, 2006 11:21 AM > To: 'Michael Haberler'; Reinaldo Penno > Cc: speermint@ietf.org; 'Uzelac, Adam' > Subject: RE: [Speermint] Source-based routing >=20 > The real issue here affects signaling and media. It appears to me that > the correct algorithm to use would be based on the offered addresses=20 > in the SDP, and which border signaling point is closest. The reasons=20 > for this are: >=20 > 1.) The signaling originator may not be co-located with the source of=20 > media. > This is often the case with Softswitch/Media Gateway sources of=20 > traffic. Its also like to be true with Softswitch Based endpoints=20 > (MGCP/NCS) where the call controller is centrally located, but the=20 > endpoints are widely distributed. >=20 > 2.) The signaling crossing point that is closes to the source of the=20 > media provides a "best crossing point" for the media as well. >=20 > Although I've resisted talking about the media --- its truly=20 > important. The location of the media crossing point, and the control=20 > of the media, are as important as any other aspect in peering. >=20 > There are some that would suggest the signaling crossing points and=20 > media crossing points are un-related. But to subsequently setup,=20 > manage, and control the media with a middle box requires the same=20 > determination of the best media crossing point. The mechanisms for=20 > doing this "locate the best middle box" are weak at best. Some say use > a policy server. However none of the policy server interfaces I have=20 > seen proposed by ETSI TISPAN, 3GPP, seem to include a "source ip=20 > address" in the request to help choose a destination ip address. While > out of the scope of this working group, one should consider the=20 > utility of the following suggestion. >=20 > I propose that the best signaling crossing point be determined based=20 > on the source of the media. This would provide for a defined crossing=20 > point that then could manage the media flows by association. >=20 > -----Original Message----- > From: Michael Haberler [mailto:mah@inode.at] > Sent: Thursday, November 09, 2006 2:38 AM > To: Reinaldo Penno > Cc: speermint@ietf.org; Uzelac, Adam > Subject: Re: [Speermint] Source-based routing >=20 > Reinaldo Penno schrieb: > > I guess the problem statement is: > > > > For a certain call, how to I find the most appropriate > egress/ingree > > peering point? > > =20 >=20 > I'm not sure wether that was what Adam meant - need to clarify >=20 > I see two interpretations: > - topological optimization of next hop (IP adress, distance..) > - a parameter into policy application - for resolution services which=20 > might give different answers to different originators >=20 >=20 >=20 > -Michael >=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 Nov 09 15:19:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiGMD-0004l4-BK; Thu, 09 Nov 2006 15:18:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiGMB-0004jD-Rz for speermint@ietf.org; Thu, 09 Nov 2006 15:18:39 -0500 Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiGMA-0001rf-7T for speermint@ietf.org; Thu, 09 Nov 2006 15:18:39 -0500 Received: from mail.nominum.com (mail.nominum.com [81.200.64.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 3337656835; Thu, 9 Nov 2006 12:18:29 -0800 (PST) (envelope-from spouliotte@nominum.com) X-Spam-Status: No, hits=0.0 required=7.0 tests=AWL: -0.041,BAYES_99: 4.07,CUSTOM_RULE_FROM: ALLOW, TOTAL_SCORE: 4.029 X-Spam-Level: Received: from [128.177.194.175] ([128.177.194.175]) (authenticated user spouliotte@nominum.com) by mail.nominum.com (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits)); Thu, 9 Nov 2006 12:18:28 -0800 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Thu, 09 Nov 2006 12:18:42 -0800 Subject: Re: [Speermint] Source-based routing From: Shawn Pouliotte To: Patrick Melampy , 'Michael Haberler' , 'Reinaldo Penno' Message-ID: Thread-Topic: [Speermint] Source-based routing Thread-Index: AccD0mSmx/4W053JRWSZEtSRwjXmOAAHaingABMMp6Y= In-Reply-To: <200611091423547.SM01656@PMelampy2> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: speermint@ietf.org, "'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 think the biggest question for me is what is important at the peering point - there are a lot of things that could theoretically be signaled but what is important? You are trying to decide if, how and where to admit traffic into a network. For this chain, yes, I was thinking about a collapsed BG model. You are alluding to a mid-com model as I read it. I only know of 1 vendor offering H.248 controlled ip to ip gateways and they are not seeing much success. I know of one other vendor that is developing in this area. The general driver for this as I understood was streamlining resources by splitting signaling and media, offering a better scaling model, better resource selection model, and h/a model. That said, I have not run into anyone that actually wanted media path in a vastly different geography from signaling. Nothing would preclude it. I am curious to hear thoughts from the carrier representatives on the list. So, with all that I certainly don't disagree that source based parameters play a role in route selection. When the group makes recommendations on those, we should understand the use cases and why they are important (in a deployable network). Shawn On 11/9/06 11:20 AM, "Patrick Melampy" wrote: > The real issue here affects signaling and media. It appears to me that the > correct algorithm to use would be based on the offered addresses in the SDP, > and which border signaling point is closest. The reasons for this are: > > 1.) The signaling originator may not be co-located with the source of media. > This is often the case with Softswitch/Media Gateway sources of traffic. Its > also like to be true with Softswitch Based endpoints (MGCP/NCS) where the > call controller is centrally located, but the endpoints are widely > distributed. > > 2.) The signaling crossing point that is closes to the source of the media > provides a "best crossing point" for the media as well. > > Although I've resisted talking about the media --- its truly important. The > location of the media crossing point, and the control of the media, are as > important as any other aspect in peering. > > There are some that would suggest the signaling crossing points and media > crossing points are un-related. But to subsequently setup, manage, and > control the media with a middle box requires the same determination of the > best media crossing point. The mechanisms for doing this "locate the best > middle box" are weak at best. Some say use a policy server. However none of > the policy server interfaces I have seen proposed by ETSI TISPAN, 3GPP, seem > to include a "source ip address" in the request to help choose a destination > ip address. While out of the scope of this working group, one should > consider the utility of the following suggestion. > > I propose that the best signaling crossing point be determined based on the > source of the media. This would provide for a defined crossing point that > then could manage the media flows by association. > > -----Original Message----- > From: Michael Haberler [mailto:mah@inode.at] > Sent: Thursday, November 09, 2006 2:38 AM > To: Reinaldo Penno > Cc: speermint@ietf.org; Uzelac, Adam > Subject: Re: [Speermint] Source-based routing > > Reinaldo Penno schrieb: >> I guess the problem statement is: >> >> For a certain call, how to I find the most appropriate egress/ingree >> peering point? >> > > I'm not sure wether that was what Adam meant - need to clarify > > I see two interpretations: > - topological optimization of next hop (IP adress, distance..) > - a parameter into policy application - for resolution services which > might give different answers to different originators > > > > -Michael > > _______________________________________________ > 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 Nov 09 15:31:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiGY3-0001zg-8b; Thu, 09 Nov 2006 15:30:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiGY1-0001yF-De for speermint@ietf.org; Thu, 09 Nov 2006 15:30:53 -0500 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiGXz-0004bF-63 for speermint@ietf.org; Thu, 09 Nov 2006 15:30:53 -0500 Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id B736D2D924; Thu, 9 Nov 2006 15:30:19 -0500 (EST) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy19.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 15:30:19 -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] Source-based routing Date: Thu, 9 Nov 2006 15:30:18 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing Thread-Index: AccD0mSmx/4W053JRWSZEtSRwjXmOAAHaingABMMp6YAAAtR0A== From: "Uzelac, Adam" To: "Shawn Pouliotte" , "Patrick Melampy" , "Michael Haberler" , "Reinaldo Penno" X-OriginalArrivalTime: 09 Nov 2006 20:30:19.0204 (UTC) FILETIME=[DF77E040:01C7043D] X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 [Shawn sayz]"I think the biggest question for me is what is important at the peering point" [adam sayz] - The pickle here is that this is very much a matter of local policy. As a VSP, all I would like is a method to know and account for things that are important to me. [Shawn sayz]"- there are a lot of things that could theoretically be signaled but what is important? " [adam sayz] Once again as a VSP, what's needed is a method to know and account for criteria that is important to my next-hop route determination. BUT what is important to me isn't necessarily important to someone else, or what's important at sunset isn't at sunrise, etc, etc. We are starting to get into requirement for the provisioning draft that David Schwartz signed himself up to developing - and this is a good thing. As I see it, queries to external registries/databases/etc to determine next-hops ultimately provide inputs for a local next-hop routing determination. =20 -AU _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Nov 09 15:36:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiGcv-0004v3-Gl; Thu, 09 Nov 2006 15:35:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiGct-0004kQ-Id for speermint@ietf.org; Thu, 09 Nov 2006 15:35:55 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiGcs-0005Sb-2r for speermint@ietf.org; Thu, 09 Nov 2006 15:35:55 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 09 Nov 2006 12:33:02 -0800 X-IronPort-AV: i="4.09,407,1157353200"; d="scan'208"; a="607254406:sNHT41444816" 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] Source-based routing Date: Thu, 9 Nov 2006 15:35:51 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280624F225@proton.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing Thread-index: AccD0mSmx/4W053JRWSZEtSRwjXmOAAHaingABMMp6YAAHkNoA== From: "Reinaldo Penno" To: "Shawn Pouliotte" , "Patrick Melampy" , "Michael Haberler" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: speermint@ietf.org, "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 Hello Shawn, the reverse is also true. If you _do not_ have a collapsed peering scheme (signaling and media crossing at the same point through media anchoring), chances are media is going to follow layer 3 routing and signaling Layer 5 (route headers, outbound proxy, etc, etc). And they might in fact go to two different completely locations. So, maybe what you actually like is for media to follow signaling after you discover the "best" (whatever that means) signaling crossing point. Regards, Reinaldo > -----Original Message----- > From: Shawn Pouliotte [mailto:Shawn.Pouliotte@nominum.com]=20 > Sent: Thursday, November 09, 2006 12:19 PM > To: Patrick Melampy; 'Michael Haberler'; Reinaldo Penno > Cc: speermint@ietf.org; 'Uzelac, Adam' > Subject: Re: [Speermint] Source-based routing >=20 > I think the biggest question for me is what is important at=20 > the peering point - there are a lot of things that could=20 > theoretically be signaled but what is important? You are=20 > trying to decide if, how and where to admit traffic into a network. >=20 >=20 > For this chain, yes, I was thinking about a collapsed BG=20 > model. You are alluding to a mid-com model as I read it. I=20 > only know of 1 vendor offering > H.248 controlled ip to ip gateways and they are not seeing=20 > much success. I know of one other vendor that is developing=20 > in this area. The general driver for this as I understood was=20 > streamlining resources by splitting signaling and media,=20 > offering a better scaling model, better resource selection=20 > model, and h/a model. That said, I have not run into anyone=20 > that actually wanted media path in a vastly different=20 > geography from signaling. Nothing would preclude it. I am=20 > curious to hear thoughts from the carrier representatives on=20 > the list.=20 >=20 > So, with all that I certainly don't disagree that source=20 > based parameters play a role in route selection. When the=20 > group makes recommendations on those, we should understand=20 > the use cases and why they are important (in a deployable network). >=20 > Shawn >=20 >=20 > On 11/9/06 11:20 AM, "Patrick Melampy"=20 > wrote: >=20 > > The real issue here affects signaling and media. It appears=20 > to me that=20 > > the correct algorithm to use would be based on the offered=20 > addresses=20 > > in the SDP, and which border signaling point is closest.=20 > The reasons for this are: > >=20 > > 1.) The signaling originator may not be co-located with the=20 > source of media. > > This is often the case with Softswitch/Media Gateway sources of=20 > > traffic. Its also like to be true with Softswitch Based endpoints=20 > > (MGCP/NCS) where the call controller is centrally located, but the=20 > > endpoints are widely distributed. > >=20 > > 2.) The signaling crossing point that is closes to the=20 > source of the=20 > > media provides a "best crossing point" for the media as well. > >=20 > > Although I've resisted talking about the media --- its truly=20 > > important. The location of the media crossing point, and=20 > the control=20 > > of the media, are as important as any other aspect in peering. > >=20 > > There are some that would suggest the signaling crossing points and=20 > > media crossing points are un-related. But to subsequently setup,=20 > > manage, and control the media with a middle box requires the same=20 > > determination of the best media crossing point. The mechanisms for=20 > > doing this "locate the best middle box" are weak at best.=20 > Some say use=20 > > a policy server. However none of the policy server=20 > interfaces I have=20 > > seen proposed by ETSI TISPAN, 3GPP, seem to include a "source ip=20 > > address" in the request to help choose a destination ip=20 > address. While=20 > > out of the scope of this working group, one should consider=20 > the utility of the following suggestion. > >=20 > > I propose that the best signaling crossing point be=20 > determined based=20 > > on the source of the media. This would provide for a=20 > defined crossing=20 > > point that then could manage the media flows by association. > >=20 > > -----Original Message----- > > From: Michael Haberler [mailto:mah@inode.at] > > Sent: Thursday, November 09, 2006 2:38 AM > > To: Reinaldo Penno > > Cc: speermint@ietf.org; Uzelac, Adam > > Subject: Re: [Speermint] Source-based routing > >=20 > > Reinaldo Penno schrieb: > >> I guess the problem statement is: > >>=20 > >> For a certain call, how to I find the most appropriate=20 > egress/ingree=20 > >> peering point? > >> =20 > >=20 > > I'm not sure wether that was what Adam meant - need to clarify > >=20 > > I see two interpretations: > > - topological optimization of next hop (IP adress, distance..) > > - a parameter into policy application - for resolution=20 > services which=20 > > might give different answers to different originators > >=20 > >=20 > >=20 > > -Michael > >=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 >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Nov 09 15:36:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiGd7-0005P1-PK; Thu, 09 Nov 2006 15:36:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiGd7-0005NL-CY for speermint@ietf.org; Thu, 09 Nov 2006 15:36:09 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GiGd5-0005W4-Oa for speermint@ietf.org; Thu, 09 Nov 2006 15:36:09 -0500 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] Source-based routing Date: Thu, 9 Nov 2006 21:33:07 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BF7@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing thread-index: AccD0mSmx/4W053JRWSZEtSRwjXmOAAHaingABHXpJAAALFfsAABBJuS References: From: "Stastny Richard" To: "Uzelac, Adam" , "Reinaldo Penno" , "Patrick Melampy" , "Michael Haberler" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 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 IMO it is in scope, but our first priority is to get a peering going at = all media is only relevant in some use cases and the problems are not easy to resolve. So it should have second priority - it will also take some time to work out the use cases, etc. =20 Richard ________________________________ Von: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] Gesendet: Do 09.11.2006 21:11 An: Reinaldo Penno; Patrick Melampy; Michael Haberler Cc: speermint@ietf.org Betreff: RE: [Speermint] Source-based routing Is there consensus around the notion that media considerations are in scope of SPEERMINT? It's not always the case, but it should be a consideration when determining next-hops route responses to a location function look-up. I would like to point out that this becomes very difficult in ENUM/DNS next-hop determinations. Hence the existence of the INVITE/3XX next-hop determination method. -AU PS - please read "media considerations" as _NOT_ meaning exclusively CODECs. -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Thursday, November 09, 2006 11:56 AM To: Patrick Melampy; Michael Haberler Cc: speermint@ietf.org; Uzelac, Adam Subject: RE: [Speermint] Source-based routing As I side note I mentioned in the IETF meeting that we keep pushing media aside and only talking about signaling but what mostly matters in terms of user experience is the media. So, I agree with you that media is important. About your suggestion below, that's a nice insight, but it is still not clear to me how from the source IP address the proxy finds the notion of "distance". Of course the first peering proxy that receives the signaling can look at number of Vias or TTL or others. But how would this proxy find out the distance between the endpoint and other peering proxies in order to send a correct 302, for instance? So, the "default" peering proxy can try to find that out (even if consulting some external DB) or the endpoint could try itself. The endpoint could send OPTION messages with increasing Max-Forwards to a coupld of proxies, or some other funky method. Thanks, Reinaldo > -----Original Message----- > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Sent: Thursday, November 09, 2006 11:21 AM > To: 'Michael Haberler'; Reinaldo Penno > Cc: speermint@ietf.org; 'Uzelac, Adam' > Subject: RE: [Speermint] Source-based routing > > The real issue here affects signaling and media. It appears to me that > the correct algorithm to use would be based on the offered addresses > in the SDP, and which border signaling point is closest. The reasons > for this are: > > 1.) The signaling originator may not be co-located with the source of > media. > This is often the case with Softswitch/Media Gateway sources of > traffic. Its also like to be true with Softswitch Based endpoints > (MGCP/NCS) where the call controller is centrally located, but the > endpoints are widely distributed. > > 2.) The signaling crossing point that is closes to the source of the > media provides a "best crossing point" for the media as well. > > Although I've resisted talking about the media --- its truly > important. The location of the media crossing point, and the control > of the media, are as important as any other aspect in peering. > > There are some that would suggest the signaling crossing points and > media crossing points are un-related. But to subsequently setup, > manage, and control the media with a middle box requires the same > determination of the best media crossing point. The mechanisms for > doing this "locate the best middle box" are weak at best. Some say use > a policy server. However none of the policy server interfaces I have > seen proposed by ETSI TISPAN, 3GPP, seem to include a "source ip > address" in the request to help choose a destination ip address. While > out of the scope of this working group, one should consider the > utility of the following suggestion. > > I propose that the best signaling crossing point be determined based > on the source of the media. This would provide for a defined crossing > point that then could manage the media flows by association. > > -----Original Message----- > From: Michael Haberler [mailto:mah@inode.at] > Sent: Thursday, November 09, 2006 2:38 AM > To: Reinaldo Penno > Cc: speermint@ietf.org; Uzelac, Adam > Subject: Re: [Speermint] Source-based routing > > Reinaldo Penno schrieb: > > I guess the problem statement is: > > > > For a certain call, how to I find the most appropriate > egress/ingree > > peering point? > > =20 > > I'm not sure wether that was what Adam meant - need to clarify > > I see two interpretations: > - topological optimization of next hop (IP adress, distance..) > - a parameter into policy application - for resolution services which > might give different answers to different originators > > > > -Michael > > _______________________________________________ > 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 Nov 09 15:45:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiGmE-00033e-Pc; Thu, 09 Nov 2006 15:45:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiGmD-00033Y-Mo for speermint@ietf.org; Thu, 09 Nov 2006 15:45:33 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GiGmC-0007Kf-0v for speermint@ietf.org; Thu, 09 Nov 2006 15:45:33 -0500 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] Source-based routing Date: Thu, 9 Nov 2006 21:44:48 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BF8@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing thread-index: AccD0mSmx/4W053JRWSZEtSRwjXmOAAHaingABMMp6YAAHkNoAAAOyEZ References: <9BD5D7887235424FA97DFC223CAE3C280624F225@proton.jnpr.net> From: "Stastny Richard" To: "Reinaldo Penno" , "Shawn Pouliotte" , "Patrick Melampy" , "Michael Haberler" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: speermint@ietf.org, "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 >So, maybe what you actually like is for media to follow signaling after >you discover the "best" (whatever that means) signaling crossing point. =20 This is exactly the problem here: I do not care about the "best" = (whatever that means ;-) signalling crossing point). The only thing that counts in source based = routing is media =20 IMO we are trying to solve a problem we have created by ourselves: First we do not use the basic peering model (end-user to end-user) for = whatever weird reason, and then we are not happy with the resulting media stream going a weird = signalling path and want to optimize it a bit, introducing a very complex next hop = routing scheme -- but not for signalling, for media =20 Richard ________________________________ Von: Reinaldo Penno [mailto:rpenno@juniper.net] Gesendet: Do 09.11.2006 21:35 An: Shawn Pouliotte; Patrick Melampy; Michael Haberler Cc: speermint@ietf.org; Uzelac, Adam Betreff: RE: [Speermint] Source-based routing Hello Shawn, the reverse is also true. If you _do not_ have a collapsed peering scheme (signaling and media crossing at the same point through media anchoring), chances are media is going to follow layer 3 routing and signaling Layer 5 (route headers, outbound proxy, etc, etc). And they might in fact go to two different completely locations. So, maybe what you actually like is for media to follow signaling after you discover the "best" (whatever that means) signaling crossing point. Regards, Reinaldo > -----Original Message----- > From: Shawn Pouliotte [mailto:Shawn.Pouliotte@nominum.com] > Sent: Thursday, November 09, 2006 12:19 PM > To: Patrick Melampy; 'Michael Haberler'; Reinaldo Penno > Cc: speermint@ietf.org; 'Uzelac, Adam' > Subject: Re: [Speermint] Source-based routing > > I think the biggest question for me is what is important at > the peering point - there are a lot of things that could > theoretically be signaled but what is important? You are > trying to decide if, how and where to admit traffic into a network. > > > For this chain, yes, I was thinking about a collapsed BG > model. You are alluding to a mid-com model as I read it. I > only know of 1 vendor offering > H.248 controlled ip to ip gateways and they are not seeing > much success. I know of one other vendor that is developing > in this area. The general driver for this as I understood was > streamlining resources by splitting signaling and media, > offering a better scaling model, better resource selection > model, and h/a model. That said, I have not run into anyone > that actually wanted media path in a vastly different > geography from signaling. Nothing would preclude it. I am > curious to hear thoughts from the carrier representatives on > the list. > > So, with all that I certainly don't disagree that source > based parameters play a role in route selection. When the > group makes recommendations on those, we should understand > the use cases and why they are important (in a deployable network). > > Shawn > > > On 11/9/06 11:20 AM, "Patrick Melampy" > wrote: > > > The real issue here affects signaling and media. It appears > to me that > > the correct algorithm to use would be based on the offered > addresses > > in the SDP, and which border signaling point is closest. > The reasons for this are: > > > > 1.) The signaling originator may not be co-located with the > source of media. > > This is often the case with Softswitch/Media Gateway sources of > > traffic. Its also like to be true with Softswitch Based endpoints > > (MGCP/NCS) where the call controller is centrally located, but the > > endpoints are widely distributed. > > > > 2.) The signaling crossing point that is closes to the > source of the > > media provides a "best crossing point" for the media as well. > > > > Although I've resisted talking about the media --- its truly > > important. The location of the media crossing point, and > the control > > of the media, are as important as any other aspect in peering. > > > > There are some that would suggest the signaling crossing points and > > media crossing points are un-related. But to subsequently setup, > > manage, and control the media with a middle box requires the same > > determination of the best media crossing point. The mechanisms for > > doing this "locate the best middle box" are weak at best. > Some say use > > a policy server. However none of the policy server > interfaces I have > > seen proposed by ETSI TISPAN, 3GPP, seem to include a "source ip > > address" in the request to help choose a destination ip > address. While > > out of the scope of this working group, one should consider > the utility of the following suggestion. > > > > I propose that the best signaling crossing point be > determined based > > on the source of the media. This would provide for a > defined crossing > > point that then could manage the media flows by association. > > > > -----Original Message----- > > From: Michael Haberler [mailto:mah@inode.at] > > Sent: Thursday, November 09, 2006 2:38 AM > > To: Reinaldo Penno > > Cc: speermint@ietf.org; Uzelac, Adam > > Subject: Re: [Speermint] Source-based routing > > > > Reinaldo Penno schrieb: > >> I guess the problem statement is: > >> > >> For a certain call, how to I find the most appropriate > egress/ingree > >> peering point? > >> =20 > > > > I'm not sure wether that was what Adam meant - need to clarify > > > > I see two interpretations: > > - topological optimization of next hop (IP adress, distance..) > > - a parameter into policy application - for resolution > services which > > might give different answers to different originators > > > > > > > > -Michael > > > > _______________________________________________ > > 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 Nov 09 15:46:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiGml-0003FI-8I; Thu, 09 Nov 2006 15:46:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiGmk-0003Ee-2k for speermint@ietf.org; Thu, 09 Nov 2006 15:46:06 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiGmi-0007Nt-Hw for speermint@ietf.org; Thu, 09 Nov 2006 15:46:06 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 09 Nov 2006 12:43:12 -0800 X-IronPort-AV: i="4.09,407,1157353200"; d="scan'208"; a="607257919:sNHT44097540" 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] Source-based routing Date: Thu, 9 Nov 2006 15:46:01 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280624F233@proton.jnpr.net> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BF7@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing Thread-index: AccD0mSmx/4W053JRWSZEtSRwjXmOAAHaingABHXpJAAALFfsAABBJuSAABxGbA= From: "Reinaldo Penno" To: "Stastny Richard" , "Uzelac, Adam" , "Patrick Melampy" , "Michael Haberler" X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 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 It is in scope "However, in order to achieve real-time Session PEERing, both signaling and media flows must be taken into consideration. In addition, the working group recognizes that there will be use cases that require SPEERMINT to focus on the interaction between the application layer and lower network layers, or the dependence of specific application layer use cases on lower layers, so SPEERMINT will have to be prepared to solve these problems as they arise." Thanks, Reinaldo=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Thursday, November 09, 2006 12:33 PM > To: Uzelac, Adam; Reinaldo Penno; Patrick Melampy; Michael Haberler > Cc: speermint@ietf.org > Subject: Re: [Speermint] Source-based routing >=20 > IMO it is in scope, but our first priority is to get a=20 > peering going at all >=20 > media is only relevant in some use cases and the problems are=20 > not easy to resolve. So it should have second priority - it=20 > will also take some time to work out the use cases, etc. > =20 > Richard >=20 > ________________________________ >=20 > Von: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Gesendet: Do 09.11.2006 21:11 > An: Reinaldo Penno; Patrick Melampy; Michael Haberler > Cc: speermint@ietf.org > Betreff: RE: [Speermint] Source-based routing >=20 >=20 >=20 > Is there consensus around the notion that media=20 > considerations are in scope of SPEERMINT? It's not always=20 > the case, but it should be a consideration when determining=20 > next-hops route responses to a location function look-up. I=20 > would like to point out that this becomes very difficult in=20 > ENUM/DNS next-hop determinations. Hence the existence of the=20 > INVITE/3XX next-hop determination method. >=20 > -AU >=20 > PS - please read "media considerations" as _NOT_ meaning=20 > exclusively CODECs. >=20 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Thursday, November 09, 2006 11:56 AM > To: Patrick Melampy; Michael Haberler > Cc: speermint@ietf.org; Uzelac, Adam > Subject: RE: [Speermint] Source-based routing >=20 > As I side note I mentioned in the IETF meeting that we keep=20 > pushing media aside and only talking about signaling but what=20 > mostly matters in terms of user experience is the media. So,=20 > I agree with you that media is important. >=20 > About your suggestion below, that's a nice insight, but it is=20 > still not clear to me how from the source IP address the=20 > proxy finds the notion of "distance". Of course the first=20 > peering proxy that receives the signaling can look at number=20 > of Vias or TTL or others. But how would this proxy find out=20 > the distance between the endpoint and other peering proxies=20 > in order to send a correct 302, for instance? >=20 > So, the "default" peering proxy can try to find that out=20 > (even if consulting some external DB) or the endpoint could=20 > try itself. The endpoint could send OPTION messages with=20 > increasing Max-Forwards to a coupld of proxies, or some other=20 > funky method. >=20 > Thanks, >=20 > Reinaldo >=20 >=20 >=20 > > -----Original Message----- > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > Sent: Thursday, November 09, 2006 11:21 AM > > To: 'Michael Haberler'; Reinaldo Penno > > Cc: speermint@ietf.org; 'Uzelac, Adam' > > Subject: RE: [Speermint] Source-based routing > > > > The real issue here affects signaling and media. It appears=20 > to me that >=20 > > the correct algorithm to use would be based on the offered=20 > addresses=20 > > in the SDP, and which border signaling point is closest.=20 > The reasons=20 > > for this are: > > > > 1.) The signaling originator may not be co-located with the=20 > source of=20 > > media. > > This is often the case with Softswitch/Media Gateway sources of=20 > > traffic. Its also like to be true with Softswitch Based endpoints > > (MGCP/NCS) where the call controller is centrally located, but the=20 > > endpoints are widely distributed. > > > > 2.) The signaling crossing point that is closes to the=20 > source of the=20 > > media provides a "best crossing point" for the media as well. > > > > Although I've resisted talking about the media --- its truly=20 > > important. The location of the media crossing point, and=20 > the control=20 > > of the media, are as important as any other aspect in peering. > > > > There are some that would suggest the signaling crossing points and=20 > > media crossing points are un-related. But to subsequently setup,=20 > > manage, and control the media with a middle box requires the same=20 > > determination of the best media crossing point. The mechanisms for=20 > > doing this "locate the best middle box" are weak at best.=20 > Some say use >=20 > > a policy server. However none of the policy server=20 > interfaces I have=20 > > seen proposed by ETSI TISPAN, 3GPP, seem to include a "source ip=20 > > address" in the request to help choose a destination ip=20 > address. While >=20 > > out of the scope of this working group, one should consider the=20 > > utility of the following suggestion. > > > > I propose that the best signaling crossing point be=20 > determined based=20 > > on the source of the media. This would provide for a=20 > defined crossing=20 > > point that then could manage the media flows by association. > > > > -----Original Message----- > > From: Michael Haberler [mailto:mah@inode.at] > > Sent: Thursday, November 09, 2006 2:38 AM > > To: Reinaldo Penno > > Cc: speermint@ietf.org; Uzelac, Adam > > Subject: Re: [Speermint] Source-based routing > > > > Reinaldo Penno schrieb: > > > I guess the problem statement is: > > > > > > For a certain call, how to I find the most appropriate > > egress/ingree > > > peering point? > > > =20 > > > > I'm not sure wether that was what Adam meant - need to clarify > > > > I see two interpretations: > > - topological optimization of next hop (IP adress, distance..) > > - a parameter into policy application - for resolution=20 > services which=20 > > might give different answers to different originators > > > > > > > > -Michael > > > > _______________________________________________ > > 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 Thu Nov 09 15:48:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiGos-0004My-6B; Thu, 09 Nov 2006 15:48:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiGor-0004Mh-8y for speermint@ietf.org; Thu, 09 Nov 2006 15:48:17 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiGof-0007vm-7F for speermint@ietf.org; Thu, 09 Nov 2006 15:48:17 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 09 Nov 2006 12:45:12 -0800 X-IronPort-AV: i="4.09,407,1157353200"; d="scan'208"; a="616887156:sNHT45061636" 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] Source-based routing Date: Thu, 9 Nov 2006 15:48:02 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280624F236@proton.jnpr.net> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BF8@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing Thread-index: AccD0mSmx/4W053JRWSZEtSRwjXmOAAHaingABMMp6YAAHkNoAAAOyEZAABNbRA= From: "Reinaldo Penno" To: "Stastny Richard" , "Shawn Pouliotte" , "Patrick Melampy" , "Michael Haberler" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: speermint@ietf.org, "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 agree about the media statement. I was just poiting out that maybe the signaling crossing path is also the best one for media. But maybe not.=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Thursday, November 09, 2006 12:45 PM > To: Reinaldo Penno; Shawn Pouliotte; Patrick Melampy; Michael Haberler > Cc: speermint@ietf.org; Uzelac, Adam > Subject: Re: [Speermint] Source-based routing >=20 > >So, maybe what you actually like is for media to follow=20 > signaling after=20 > >you discover the "best" (whatever that means) signaling=20 > crossing point. > =20 > This is exactly the problem here: I do not care about the=20 > "best" (whatever that means ;-) signalling crossing point).=20 > The only thing that counts in source based routing is media > =20 > IMO we are trying to solve a problem we have created by ourselves: >=20 > First we do not use the basic peering model (end-user to=20 > end-user) for whatever weird reason, and then we are not=20 > happy with the resulting media stream going a weird=20 > signalling path and want to optimize it a bit, introducing a=20 > very complex next hop routing scheme -- but not for=20 > signalling, for media > =20 > Richard >=20 > ________________________________ >=20 > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Do 09.11.2006 21:35 > An: Shawn Pouliotte; Patrick Melampy; Michael Haberler > Cc: speermint@ietf.org; Uzelac, Adam > Betreff: RE: [Speermint] Source-based routing >=20 >=20 >=20 > Hello Shawn, >=20 > the reverse is also true. If you _do not_ have a collapsed=20 > peering scheme (signaling and media crossing at the same=20 > point through media anchoring), chances are media is going to=20 > follow layer 3 routing and signaling Layer 5 (route headers,=20 > outbound proxy, etc, etc). And they might in fact go to two=20 > different completely locations. >=20 > So, maybe what you actually like is for media to follow=20 > signaling after you discover the "best" (whatever that means)=20 > signaling crossing point. >=20 > Regards, >=20 > Reinaldo >=20 > > -----Original Message----- > > From: Shawn Pouliotte [mailto:Shawn.Pouliotte@nominum.com] > > Sent: Thursday, November 09, 2006 12:19 PM > > To: Patrick Melampy; 'Michael Haberler'; Reinaldo Penno > > Cc: speermint@ietf.org; 'Uzelac, Adam' > > Subject: Re: [Speermint] Source-based routing > > > > I think the biggest question for me is what is important at the=20 > > peering point - there are a lot of things that could=20 > theoretically be=20 > > signaled but what is important? You are trying to decide=20 > if, how and=20 > > where to admit traffic into a network. > > > > > > For this chain, yes, I was thinking about a collapsed BG model. You=20 > > are alluding to a mid-com model as I read it. I only know=20 > of 1 vendor=20 > > offering > > H.248 controlled ip to ip gateways and they are not seeing much=20 > > success. I know of one other vendor that is developing in=20 > this area.=20 > > The general driver for this as I understood was=20 > streamlining resources=20 > > by splitting signaling and media, offering a better scaling model,=20 > > better resource selection model, and h/a model. That said,=20 > I have not=20 > > run into anyone that actually wanted media path in a vastly=20 > different=20 > > geography from signaling. Nothing would preclude it. I am=20 > curious to=20 > > hear thoughts from the carrier representatives on the list. > > > > So, with all that I certainly don't disagree that source based=20 > > parameters play a role in route selection. When the group makes=20 > > recommendations on those, we should understand the use=20 > cases and why=20 > > they are important (in a deployable network). > > > > Shawn > > > > > > On 11/9/06 11:20 AM, "Patrick Melampy" > > wrote: > > > > > The real issue here affects signaling and media. It appears > > to me that > > > the correct algorithm to use would be based on the offered > > addresses > > > in the SDP, and which border signaling point is closest. > > The reasons for this are: > > > > > > 1.) The signaling originator may not be co-located with the > > source of media. > > > This is often the case with Softswitch/Media Gateway sources of=20 > > > traffic. Its also like to be true with Softswitch Based endpoints > > > (MGCP/NCS) where the call controller is centrally=20 > located, but the=20 > > > endpoints are widely distributed. > > > > > > 2.) The signaling crossing point that is closes to the > > source of the > > > media provides a "best crossing point" for the media as well. > > > > > > Although I've resisted talking about the media --- its truly=20 > > > important. The location of the media crossing point, and > > the control > > > of the media, are as important as any other aspect in peering. > > > > > > There are some that would suggest the signaling crossing=20 > points and=20 > > > media crossing points are un-related. But to subsequently setup,=20 > > > manage, and control the media with a middle box requires the same=20 > > > determination of the best media crossing point. The=20 > mechanisms for=20 > > > doing this "locate the best middle box" are weak at best. > > Some say use > > > a policy server. However none of the policy server > > interfaces I have > > > seen proposed by ETSI TISPAN, 3GPP, seem to include a "source ip=20 > > > address" in the request to help choose a destination ip > > address. While > > > out of the scope of this working group, one should consider > > the utility of the following suggestion. > > > > > > I propose that the best signaling crossing point be > > determined based > > > on the source of the media. This would provide for a > > defined crossing > > > point that then could manage the media flows by association. > > > > > > -----Original Message----- > > > From: Michael Haberler [mailto:mah@inode.at] > > > Sent: Thursday, November 09, 2006 2:38 AM > > > To: Reinaldo Penno > > > Cc: speermint@ietf.org; Uzelac, Adam > > > Subject: Re: [Speermint] Source-based routing > > > > > > Reinaldo Penno schrieb: > > >> I guess the problem statement is: > > >> > > >> For a certain call, how to I find the most appropriate > > egress/ingree > > >> peering point? > > >> =20 > > > > > > I'm not sure wether that was what Adam meant - need to clarify > > > > > > I see two interpretations: > > > - topological optimization of next hop (IP adress, distance..) > > > - a parameter into policy application - for resolution > > services which > > > might give different answers to different originators > > > > > > > > > > > > -Michael > > > > > > _______________________________________________ > > > 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 Thu Nov 09 16:11:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHAq-0001fo-Rp; Thu, 09 Nov 2006 16:11:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHAp-0001fe-PO for speermint@ietf.org; Thu, 09 Nov 2006 16:10:59 -0500 Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiHAm-0003Ju-RH for speermint@ietf.org; Thu, 09 Nov 2006 16:10:59 -0500 Received: from mail.nominum.com (mail.nominum.com [81.200.64.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 712B75685A; Thu, 9 Nov 2006 13:10:56 -0800 (PST) (envelope-from spouliotte@nominum.com) X-Spam-Status: No, hits=0.0 required=7.0 tests=AWL: -0.040,BAYES_99: 4.07,CUSTOM_RULE_FROM: ALLOW, TOTAL_SCORE: 4.030 X-Spam-Level: Received: from [128.177.194.175] ([128.177.194.175]) (authenticated user spouliotte@nominum.com) by mail.nominum.com (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits)); Thu, 9 Nov 2006 13:10:54 -0800 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Thu, 09 Nov 2006 13:11:11 -0800 Subject: Re: [Speermint] Source-based routing From: Shawn Pouliotte To: "Uzelac, Adam" , Patrick Melampy , Michael Haberler , Reinaldo Penno Message-ID: Thread-Topic: [Speermint] Source-based routing Thread-Index: AccD0mSmx/4W053JRWSZEtSRwjXmOAAHaingABMMp6YAAAtR0AAByeyu In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Adam, I completely understand you and agree 100%. The difficulty I have is that a vague requirement will lead to huge variation in implementation. At the end of all this, people will implement products to try and address the needs. For the various scenarios, what are the needs? For example, is there a use case in peering where I might want to route on "s=" in an SDP? I would think not but maybe there is. I agree that source information is important, but what is the minimum set? Perhaps the provisioning requirements will flesh this out but provisioning will also cover administrative concepts that are out of scope of signaling. K - I'll try and shut up now. Lets see where the provisioning requirements take us. Shawn On 11/9/06 12:30 PM, "Uzelac, Adam" wrote: > what's needed is a method to know and > account for criteria that is important to my next-hop route > determination. BUT what is important to me isn't necessarily important > to someone else, or what's important at sunset isn't at sunrise, etc, > etc. We are starting to get into requirement for the provisioning draft > that David Schwartz signed himself up to developing - and this is a good > thing. > > As I see it, queries to external registries/databases/etc to determine > next-hops ultimately provide inputs for a local next-hop routing > determination. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Nov 09 17:04:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiI0N-0000mZ-7w; Thu, 09 Nov 2006 17:04:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiI0M-0000mT-1k for speermint@ietf.org; Thu, 09 Nov 2006 17:04:14 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiI0K-0002yR-K5 for speermint@ietf.org; Thu, 09 Nov 2006 17:04:14 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id BBF744D464; Thu, 9 Nov 2006 23:04:07 +0100 (CET) Date: Thu, 9 Nov 2006 23:04:07 +0100 From: Otmar Lendl To: Patrick Melampy Subject: Re: [Speermint] Source-based routing Message-ID: <20061109220407.GB3601@nic.at> Mail-Followup-To: Otmar Lendl , Patrick Melampy , 'Michael Haberler' , 'Reinaldo Penno' , speermint@ietf.org, "'Uzelac, Adam'" References: <4552DABE.4060108@inode.at> <00b101c70434$996545b0$800101df@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00b101c70434$996545b0$800101df@acmepacket.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: speermint@ietf.org, "'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 On 2006/11/09 20:11, Patrick Melampy wrote: > The real issue here affects signaling and media. It appears to me that the > correct algorithm to use would be based on the offered addresses in the SDP, > and which border signaling point is closest. "closest" is optional. "reachable" is the important issue. Consider VSP networks connected to each other via various VoIP-peering setups (e.g. special VLANs at Internet exchanges like LINX, AMSIX & co that are not routed on the Internet). Example: Let VSP1 be connected to IX-A and IX-B Let VSP2 be connected to IX-B and IX-C Let VSP3 be connected to IX-A and IX-C a) If VSP1 wants to reach VSP2, that call needs to go via IX-B. b) If VSP3 wants to reach VSP2, he needs go via IX-C, thus a different ingress point into VSP2. If we have URI based addressing and use the global DNS, we have a problem here with straight forward SRV/A lookups. Whatever you put in there, you will give unusable answers to half of the queries and expect the caller to fall back to the second avertized ingress point. This will not scale with the number of such IXs out there. There are a number of ways to solve this: * The location-function is local to the IX-*. In that case, in a) the LF in IX-B will tell VSP1 the ingress point of VSP2 which resides within IX-B On the other hand, in b) the LF in IX-C will return a different ingress point for VSP2, namely the one in IX-C. This does not scale all too well as parallel/sequential queries into all LFs of all IXs are needed. * Let VSP2 operate a sip proxy on the open internet which uses 3xx replies to direct VSP1 and VSP3 to ingress points within the IX-* networks. * Manual configuration. The source network has local configuration regarding what ingress element it is supposed to target when talking to a certain destination (as defined by domain or E.164 prefix). * Changes to the domain -> ingress algorithm (i.e. rfc3263). * Add IX- membership indications to the DNS. Thus the source VSP can use a IX-specific algorithm for ingress discovery. (that's what I propose in http://tools.ietf.org/wg/speermint/draft-lendl-speermint-federations-03.txt ) In other words: Plain ENUM/RFC3263 won't cut it. We can add the source-dependency (or IX-dependency) at various steps in the lookup chain. I just don't see a way around that. /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 Nov 11 15:36:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GizYZ-0005RO-6B; Sat, 11 Nov 2006 15:34:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GizYX-0005Q9-DI for speermint@ietf.org; Sat, 11 Nov 2006 15:34:25 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GizYU-0006sI-Si for speermint@ietf.org; Sat, 11 Nov 2006 15:34:24 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 11 Nov 2006 12:34:21 -0800 X-IronPort-AV: i="4.09,413,1157353200"; d="scan'208"; a="1270403:sNHT58035870" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kABKYLbV009411; Sat, 11 Nov 2006 15:34:21 -0500 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 kABKYGDM024581; Sat, 11 Nov 2006 15:34:16 -0500 (EST) 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.1830); Sat, 11 Nov 2006 15:34:16 -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] Source-based routing Date: Sat, 11 Nov 2006 15:34:15 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3022DB44A@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing Thread-Index: AccD0mSmx/4W053JRWSZEtSRwjXmOAAHaingAHfYOkA= From: "Michael Hammer \(mhammer\)" To: "Patrick Melampy" , "Michael Haberler" , "Reinaldo Penno" X-OriginalArrivalTime: 11 Nov 2006 20:34:16.0405 (UTC) FILETIME=[C1AD6050:01C705D0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3880; t=1163277261; x=1164141261; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:=20RE=3A=20[Speermint]=20Source-based=20routing |Sender:=20 |To:=20=22Patrick=20Melampy=22=20, =0A=20=20=20=2 0=20=20=20=20=22Michael=20Haberler=22=20, =0A=20=20=20=20=20= 20=20=20=22Reinaldo=20Penno=22=20; bh=URJo7caAUPjohhDgro6N25X2b/9j0QNhbrMFJKNUzv4=; b=ihgsNbq3ysi8az65eT8srOTY7MJ1EvM34mmDGRWPue6nH8Gkh6HE39upn+5Lu5IbofFVGYID boztpN/xuYFfDQPU5eSND20KgXgZwThqijed216Zm599tu9Z7PkWXtB5; Authentication-Results: rtp-dkim-1; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: speermint@ietf.org, "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 Chasing down this thread. In general, I think that intertwining the signaling point entry and media point entry might be a mistake. I would prefer to keep these decisions decoupled. What do you do if the media location is unknown at initial setup time, but perhaps known later in the flow? What do you do if the media location changes during the call setup? What if the media crossing point is from one access network, but the signaling crossing point is from the home provider? Maybe it won't make a difference, but creating such constraints seems to make the solution more brittle. Mike > -----Original Message----- > From: Patrick Melampy [mailto:PMelampy@acmepacket.com]=20 > Sent: Thursday, November 09, 2006 2:21 PM > To: 'Michael Haberler'; 'Reinaldo Penno' > Cc: speermint@ietf.org; 'Uzelac, Adam' > Subject: RE: [Speermint] Source-based routing >=20 > The real issue here affects signaling and media. It appears=20 > to me that the correct algorithm to use would be based on the=20 > offered addresses in the SDP, and which border signaling=20 > point is closest. The reasons for this are: >=20 > 1.) The signaling originator may not be co-located with the=20 > source of media. > This is often the case with Softswitch/Media Gateway sources=20 > of traffic. Its also like to be true with Softswitch Based=20 > endpoints (MGCP/NCS) where the call controller is centrally=20 > located, but the endpoints are widely distributed. >=20 > 2.) The signaling crossing point that is closes to the source=20 > of the media provides a "best crossing point" for the media as well. >=20 > Although I've resisted talking about the media --- its truly=20 > important. The location of the media crossing point, and the=20 > control of the media, are as important as any other aspect in=20 > peering.=20 >=20 > There are some that would suggest the signaling crossing=20 > points and media crossing points are un-related. But to=20 > subsequently setup, manage, and control the media with a=20 > middle box requires the same determination of the best media=20 > crossing point. The mechanisms for doing this "locate the=20 > best middle box" are weak at best. Some say use a policy=20 > server. However none of the policy server interfaces I have=20 > seen proposed by ETSI TISPAN, 3GPP, seem to include a "source=20 > ip address" in the request to help choose a destination ip=20 > address. While out of the scope of this working group, one=20 > should consider the utility of the following suggestion. >=20 > I propose that the best signaling crossing point be=20 > determined based on the source of the media. This would=20 > provide for a defined crossing point that then could manage=20 > the media flows by association. >=20 > -----Original Message----- > From: Michael Haberler [mailto:mah@inode.at] > Sent: Thursday, November 09, 2006 2:38 AM > To: Reinaldo Penno > Cc: speermint@ietf.org; Uzelac, Adam > Subject: Re: [Speermint] Source-based routing >=20 > Reinaldo Penno schrieb: > > I guess the problem statement is: > > > > For a certain call, how to I find the most appropriate=20 > egress/ingree=20 > > peering point? > > =20 >=20 > I'm not sure wether that was what Adam meant - need to clarify >=20 > I see two interpretations: > - topological optimization of next hop (IP adress, distance..) > - a parameter into policy application - for resolution=20 > services which might give different answers to different originators >=20 >=20 >=20 > -Michael >=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 Sat Nov 11 15:37:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GizbG-0006Yr-1u; Sat, 11 Nov 2006 15:37:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GizbE-0006Yd-VL for speermint@ietf.org; Sat, 11 Nov 2006 15:37:12 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GizbD-0007n6-7w for speermint@ietf.org; Sat, 11 Nov 2006 15:37:12 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 11 Nov 2006 12:37:10 -0800 X-IronPort-AV: i="4.09,413,1157353200"; d="scan'208"; a="1270906:sNHT70428978" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kABKb9NL009842; Sat, 11 Nov 2006 15:37:09 -0500 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 kABKb9YJ024297; Sat, 11 Nov 2006 15:37:09 -0500 (EST) 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.1830); Sat, 11 Nov 2006 15:37:09 -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] Source-based routing Date: Sat, 11 Nov 2006 15:37:08 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3022DB44B@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing Thread-Index: AccD0mSmx/4W053JRWSZEtSRwjXmOAAHaingABMMp6YAAHkNoABkvpag From: "Michael Hammer \(mhammer\)" To: "Reinaldo Penno" , "Shawn Pouliotte" , "Patrick Melampy" , "Michael Haberler" X-OriginalArrivalTime: 11 Nov 2006 20:37:09.0232 (UTC) FILETIME=[28B0AF00:01C705D1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6205; t=1163277429; x=1164141429; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:=20RE=3A=20[Speermint]=20Source-based=20routing |Sender:=20 |To:=20=22Reinaldo=20Penno=22=20, =0A=20=20=20=20=20=2 0=20=20=22Shawn=20Pouliotte=22=20, =0A=20=20=2 0=20=20=20=20=20=22Patrick=20Melampy=22=20, =0A=20 =20=20=20=20=20=20=20=22Michael=20Haberler=22=20; bh=nTwMEYoyMVl3CCa+08uhGTry/XiZ0hm2EWqu3K7r58M=; b=ZaLWf33s/B2u2TOZO9FPPBaSRkuUb3j1E0Nbnsdoe6ts9paQgKzRfRbmwAgvxsdFAF0RPE6g RXFkCDZDNGkgwrL02btkdNukt488zTJqCg5srqbeHqzFgpvFrGlfJNye; Authentication-Results: rtp-dkim-1; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: speermint@ietf.org, "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 So, the media now follows a non-optimal path? Mike =20 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 > Sent: Thursday, November 09, 2006 3:36 PM > To: Shawn Pouliotte; Patrick Melampy; Michael Haberler > Cc: speermint@ietf.org; Uzelac, Adam > Subject: RE: [Speermint] Source-based routing >=20 > Hello Shawn, >=20 > the reverse is also true. If you _do not_ have a collapsed=20 > peering scheme (signaling and media crossing at the same=20 > point through media anchoring), chances are media is going to=20 > follow layer 3 routing and signaling Layer 5 (route headers,=20 > outbound proxy, etc, etc). And they might in fact go to two=20 > different completely locations. >=20 > So, maybe what you actually like is for media to follow=20 > signaling after you discover the "best" (whatever that means)=20 > signaling crossing point. >=20 > Regards, >=20 > Reinaldo >=20 > > -----Original Message----- > > From: Shawn Pouliotte [mailto:Shawn.Pouliotte@nominum.com] > > Sent: Thursday, November 09, 2006 12:19 PM > > To: Patrick Melampy; 'Michael Haberler'; Reinaldo Penno > > Cc: speermint@ietf.org; 'Uzelac, Adam' > > Subject: Re: [Speermint] Source-based routing > >=20 > > I think the biggest question for me is what is important at the=20 > > peering point - there are a lot of things that could=20 > theoretically be=20 > > signaled but what is important? You are trying to decide=20 > if, how and=20 > > where to admit traffic into a network. > >=20 > >=20 > > For this chain, yes, I was thinking about a collapsed BG model. You=20 > > are alluding to a mid-com model as I read it. I only know=20 > of 1 vendor=20 > > offering > > H.248 controlled ip to ip gateways and they are not seeing much=20 > > success. I know of one other vendor that is developing in=20 > this area.=20 > > The general driver for this as I understood was=20 > streamlining resources=20 > > by splitting signaling and media, offering a better scaling model,=20 > > better resource selection model, and h/a model. That said,=20 > I have not=20 > > run into anyone that actually wanted media path in a vastly=20 > different=20 > > geography from signaling. Nothing would preclude it. I am=20 > curious to=20 > > hear thoughts from the carrier representatives on the list. > >=20 > > So, with all that I certainly don't disagree that source based=20 > > parameters play a role in route selection. When the group makes=20 > > recommendations on those, we should understand the use=20 > cases and why=20 > > they are important (in a deployable network). > >=20 > > Shawn > >=20 > >=20 > > On 11/9/06 11:20 AM, "Patrick Melampy"=20 > > wrote: > >=20 > > > The real issue here affects signaling and media. It appears > > to me that > > > the correct algorithm to use would be based on the offered > > addresses > > > in the SDP, and which border signaling point is closest.=20 > > The reasons for this are: > > >=20 > > > 1.) The signaling originator may not be co-located with the > > source of media. > > > This is often the case with Softswitch/Media Gateway sources of=20 > > > traffic. Its also like to be true with Softswitch Based endpoints > > > (MGCP/NCS) where the call controller is centrally=20 > located, but the=20 > > > endpoints are widely distributed. > > >=20 > > > 2.) The signaling crossing point that is closes to the > > source of the > > > media provides a "best crossing point" for the media as well. > > >=20 > > > Although I've resisted talking about the media --- its truly=20 > > > important. The location of the media crossing point, and > > the control > > > of the media, are as important as any other aspect in peering. > > >=20 > > > There are some that would suggest the signaling crossing=20 > points and=20 > > > media crossing points are un-related. But to subsequently setup,=20 > > > manage, and control the media with a middle box requires the same=20 > > > determination of the best media crossing point. The=20 > mechanisms for=20 > > > doing this "locate the best middle box" are weak at best. > > Some say use > > > a policy server. However none of the policy server > > interfaces I have > > > seen proposed by ETSI TISPAN, 3GPP, seem to include a "source ip=20 > > > address" in the request to help choose a destination ip > > address. While > > > out of the scope of this working group, one should consider > > the utility of the following suggestion. > > >=20 > > > I propose that the best signaling crossing point be > > determined based > > > on the source of the media. This would provide for a > > defined crossing > > > point that then could manage the media flows by association. > > >=20 > > > -----Original Message----- > > > From: Michael Haberler [mailto:mah@inode.at] > > > Sent: Thursday, November 09, 2006 2:38 AM > > > To: Reinaldo Penno > > > Cc: speermint@ietf.org; Uzelac, Adam > > > Subject: Re: [Speermint] Source-based routing > > >=20 > > > Reinaldo Penno schrieb: > > >> I guess the problem statement is: > > >>=20 > > >> For a certain call, how to I find the most appropriate > > egress/ingree > > >> peering point? > > >> =20 > > >=20 > > > I'm not sure wether that was what Adam meant - need to clarify > > >=20 > > > I see two interpretations: > > > - topological optimization of next hop (IP adress, distance..) > > > - a parameter into policy application - for resolution > > services which > > > might give different answers to different originators > > >=20 > > >=20 > > >=20 > > > -Michael > > >=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 > >=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 Sat Nov 11 16:10:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj07B-0001MX-7w; Sat, 11 Nov 2006 16:10:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj07A-0001LH-G1 for speermint@ietf.org; Sat, 11 Nov 2006 16:10:12 -0500 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 1Gj077-0001ez-Se for speermint@ietf.org; Sat, 11 Nov 2006 16:10:12 -0500 Received: from PMelampy2 [68.189.242.21] by acmepacket.com with ESMTP (SMTPD-9.10) id AC1601B0; Sat, 11 Nov 2006 16:09:42 -0500 From: "Patrick Melampy" To: "'Michael Hammer \(mhammer\)'" , Subject: RE: [Speermint] Source-based routing Date: Sat, 11 Nov 2006 16:09:39 -0500 Message-ID: <02a801c705d5$b6f30020$800101df@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccD0mSmx/4W053JRWSZEtSRwjXmOAAHaingAHfYOkAAAHPTsAAAbhKAAAAaClA= In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3022DB44D@xmb-rtp-20b.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.1 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 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 Forgetting media for now -- But what we need to focus on..... Imagine you run a network....and so do I We both have many proxies -- lets just say 100. We both want to run our networks independently.... a.) Add new proxies b.) Service proxies c.) remove proxies What is important for this standard body is to define protocols and BCPs that will let carriers communicate the aspects of adjacency that are necessary -- no more. I would suggest minimally we need to exchange lists of proxies I would also suggest we might improve our efficiencies of routing if we also exchanged some attributes based on our service level agreement a.) Rates and speeds b.) volumes by location The question is...are all proxies equal? Should the call originating side care which destination side proxy is chosen? Should it be consistent if possible? Is there benefit to having it controllable and definable? If I were a carrier, I would want the following 1.) I would want my proxies logically paired with the proxies on the other side. This would improve detection of service impairments and route-around logic. It would also be easier to debug and maintain. 2.) I would want secondary proxies for backup on both sides. 3.) I would want to know what the "offered capacity" the destination proxy is offering to me for my use. This includes counts of calls, and kilobytes of media. It seems to me that selection of a proxy on the "local" side would then be logically selecting a proxy on the "far" side. This is actually congruent with what ETSI TISPAN and MSF are proposing for their Peering Edges between carriers. Both sides would have a proxy specifically used for Peering. So the logic for selecting a crossing point is all local to each network. So maybe it is truly out of scope if we can agree that there are edge proxies that establish a real or logical "pairing" at peering borders? Is this reasonable? Or am I once again smoking crack. -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Saturday, November 11, 2006 3:51 PM To: Patrick Melampy; Michael Haberler; Reinaldo Penno Cc: Uzelac, Adam Subject: RE: [Speermint] Source-based routing : PRIVATE This may really be an implementation detail that does not need standardization. Mike > -----Original Message----- > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Sent: Saturday, November 11, 2006 3:46 PM > To: Michael Hammer (mhammer); 'Michael Haberler'; 'Reinaldo Penno' > Cc: 'Uzelac, Adam' > Subject: RE: [Speermint] Source-based routing : PRIVATE > > Your of course correct. In an ideal world, we would just let > the source and destination stream packets directly to each > other. However, there may be a desire to use a middle box of > some kind for business and security reasons. > If one is to use a middle box or media relay, the algorithm > for selecting one (when there are many possible) is very difficult. > > In the ETSI TISPAN and MSF groups, they are proposing a > "policy" layer between the signaling layer, and the media > relays. This policy layer would in theory be able to "figure > out" where the best media location is. I find this mechanism > horrible for the reasons you suggest. Lots of spread out > state, that can easily get screwed up with complex call flows. > > It might be heresy to suggest this....but a Transparent B2BUA > that also transparently manages the MEDIA could be very > effective and simple. Lets define transparency as a device > that does not modify any data that defines a dialogue. This > is in effect a Session Border Controller. Some day, the > standards bodies will come to grips with the business > realities that carriers have, and the desire that simpler is better. > > Although I wouldn't propose this to the spearmint group as > its not really in scope, I just wanted to suggest that we > focus on selection of the best proxy with the assumption that > it is "nearby" where the media should cross. This will work > with any solution being proposed (ETSI TISPAN/MSF/IETF). > Seems reasonable. > > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Saturday, November 11, 2006 3:34 PM > To: Patrick Melampy; Michael Haberler; Reinaldo Penno > Cc: speermint@ietf.org; Uzelac, Adam > Subject: RE: [Speermint] Source-based routing > > Chasing down this thread. > > In general, I think that intertwining the signaling point > entry and media point entry might be a mistake. I would > prefer to keep these decisions decoupled. What do you do if > the media location is unknown at initial setup time, but > perhaps known later in the flow? What do you do if the media > location changes during the call setup? What if the media > crossing point is from one access network, but the signaling > crossing point is from the home provider? > > Maybe it won't make a difference, but creating such > constraints seems to make the solution more brittle. > > Mike > > > > -----Original Message----- > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > Sent: Thursday, November 09, 2006 2:21 PM > > To: 'Michael Haberler'; 'Reinaldo Penno' > > Cc: speermint@ietf.org; 'Uzelac, Adam' > > Subject: RE: [Speermint] Source-based routing > > > > The real issue here affects signaling and media. It appears > to me that > > the correct algorithm to use would be based on the offered > addresses > > in the SDP, and which border signaling point is closest. > The reasons > > for this are: > > > > 1.) The signaling originator may not be co-located with the > source of > > media. > > This is often the case with Softswitch/Media Gateway sources of > > traffic. Its also like to be true with Softswitch Based endpoints > > (MGCP/NCS) where the call controller is centrally located, but the > > endpoints are widely distributed. > > > > 2.) The signaling crossing point that is closes to the > source of the > > media provides a "best crossing point" for the media as well. > > > > Although I've resisted talking about the media --- its truly > > important. The location of the media crossing point, and > the control > > of the media, are as important as any other aspect in peering. > > > > There are some that would suggest the signaling crossing points and > > media crossing points are un-related. But to subsequently setup, > > manage, and control the media with a middle box requires the same > > determination of the best media crossing point. The mechanisms for > > doing this "locate the best middle box" are weak at best. > Some say use > > a policy server. However none of the policy server > interfaces I have > > seen proposed by ETSI TISPAN, 3GPP, seem to include a "source ip > > address" in the request to help choose a destination ip > address. While > > out of the scope of this working group, one should consider the > > utility of the following suggestion. > > > > I propose that the best signaling crossing point be > determined based > > on the source of the media. This would provide for a > defined crossing > > point that then could manage the media flows by association. > > > > -----Original Message----- > > From: Michael Haberler [mailto:mah@inode.at] > > Sent: Thursday, November 09, 2006 2:38 AM > > To: Reinaldo Penno > > Cc: speermint@ietf.org; Uzelac, Adam > > Subject: Re: [Speermint] Source-based routing > > > > Reinaldo Penno schrieb: > > > I guess the problem statement is: > > > > > > For a certain call, how to I find the most appropriate > > egress/ingree > > > peering point? > > > > > > > I'm not sure wether that was what Adam meant - need to clarify > > > > I see two interpretations: > > - topological optimization of next hop (IP adress, distance..) > > - a parameter into policy application - for resolution > services which > > might give different answers to different originators > > > > > > > > -Michael > > > > _______________________________________________ > > 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 Nov 11 16:17:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj0DT-0000ok-R4; Sat, 11 Nov 2006 16:16:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj0DS-0000oY-8p for speermint@ietf.org; Sat, 11 Nov 2006 16:16:42 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj0DP-0003m2-II for speermint@ietf.org; Sat, 11 Nov 2006 16:16:42 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-5.cisco.com with ESMTP; 11 Nov 2006 13:16:38 -0800 X-IronPort-AV: i="4.09,413,1157353200"; d="scan'208"; a="343287691:sNHT69488548" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kABLGcTG015796; Sat, 11 Nov 2006 16:16:38 -0500 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 kABLGbDM029169; Sat, 11 Nov 2006 16:16:37 -0500 (EST) 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.1830); Sat, 11 Nov 2006 16:16:36 -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] Source-based routing Date: Sat, 11 Nov 2006 16:16:35 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3022DB44E@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing Thread-Index: AccD0mSmx/4W053JRWSZEtSRwjXmOAAHaingAHfYOkAAAHPTsAAAbhKAAAAaClAAAMFAgA== From: "Michael Hammer \(mhammer\)" To: "Patrick Melampy" , X-OriginalArrivalTime: 11 Nov 2006 21:16:36.0991 (UTC) FILETIME=[ABFC08F0:01C705D6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9791; t=1163279798; x=1164143798; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:=20RE=3A=20[Speermint]=20Source-based=20routing |Sender:=20 |To:=20=22Patrick=20Melampy=22=20, =20; bh=5MvOkwD0QkfJ6sOLI8HK4++HnLFDK6VI+DmF5KW/Ddk=; b=V4VBTVvaOPDzVGW15FyQc7MTOUby+sO2FFbOYApuzMm9TQTQkIB6xND6augUqfTXskM6jHQt qjVsVR4HrRa3uIIX93veubED7Jem3LNkclGPz3dFf2V8wkaN4NwQ9WRt; Authentication-Results: rtp-dkim-1; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa 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 Somehow the idea of "pairing" seems overly restrictive. While there may exist a pair of proxies that regularly communicate with each other, I would not expect those proxies to be monogamous. :) That is, the same proxy communicating to SP A may also be a point of entry for SP B. Mike =20 > -----Original Message----- > From: Patrick Melampy [mailto:PMelampy@acmepacket.com]=20 > Sent: Saturday, November 11, 2006 4:10 PM > To: Michael Hammer (mhammer); speermint@ietf.org > Subject: RE: [Speermint] Source-based routing >=20 > Forgetting media for now -- >=20 > But what we need to focus on..... >=20 > Imagine you run a network....and so do I >=20 > We both have many proxies -- lets just say 100. >=20 > We both want to run our networks independently.... > a.) Add new proxies > b.) Service proxies > c.) remove proxies >=20 > What is important for this standard body is to define=20 > protocols and BCPs that will let carriers communicate the=20 > aspects of adjacency that are necessary -- no more. >=20 > I would suggest minimally we need to exchange lists of=20 > proxies I would also suggest we might improve our=20 > efficiencies of routing if we also exchanged some attributes=20 > based on our service level agreement > a.) Rates and speeds > b.) volumes by location >=20 > The question is...are all proxies equal? Should the call=20 > originating side care which destination side proxy is chosen?=20 > Should it be consistent if possible? Is there benefit to=20 > having it controllable and definable?=20 >=20 > If I were a carrier, I would want the following > 1.) I would want my proxies logically paired with the proxies=20 > on the other side. This would improve detection of service=20 > impairments and route-around logic. It would also be easier=20 > to debug and maintain. > 2.) I would want secondary proxies for backup on both sides.=20 > 3.) I would want to know what the "offered capacity" the=20 > destination proxy is offering to me for my use. This includes=20 > counts of calls, and kilobytes of media. >=20 > It seems to me that selection of a proxy on the "local" side=20 > would then be logically selecting a proxy on the "far" side.=20 > This is actually congruent with what ETSI TISPAN and MSF are=20 > proposing for their Peering Edges between carriers. Both=20 > sides would have a proxy specifically used for Peering. So=20 > the logic for selecting a crossing point is all local to each network. >=20 > So maybe it is truly out of scope if we can agree that there=20 > are edge proxies that establish a real or logical "pairing"=20 > at peering borders? >=20 > Is this reasonable? Or am I once again smoking crack. >=20 >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Saturday, November 11, 2006 3:51 PM > To: Patrick Melampy; Michael Haberler; Reinaldo Penno > Cc: Uzelac, Adam > Subject: RE: [Speermint] Source-based routing : PRIVATE >=20 > This may really be an implementation detail that does not=20 > need standardization. >=20 > Mike > =20 >=20 > > -----Original Message----- > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > Sent: Saturday, November 11, 2006 3:46 PM > > To: Michael Hammer (mhammer); 'Michael Haberler'; 'Reinaldo Penno' > > Cc: 'Uzelac, Adam' > > Subject: RE: [Speermint] Source-based routing : PRIVATE > >=20 > > Your of course correct. In an ideal world, we would just let the=20 > > source and destination stream packets directly to each=20 > other. However,=20 > > there may be a desire to use a middle box of some kind for business=20 > > and security reasons. > > If one is to use a middle box or media relay, the algorithm for=20 > > selecting one (when there are many possible) is very difficult. > >=20 > > In the ETSI TISPAN and MSF groups, they are proposing a=20 > "policy" layer=20 > > between the signaling layer, and the media relays. This=20 > policy layer=20 > > would in theory be able to "figure out" where the best=20 > media location=20 > > is. I find this mechanism horrible for the reasons you=20 > suggest. Lots=20 > > of spread out state, that can easily get screwed up with=20 > complex call=20 > > flows. > >=20 > > It might be heresy to suggest this....but a Transparent B2BUA that=20 > > also transparently manages the MEDIA could be very effective and=20 > > simple. Lets define transparency as a device that does not=20 > modify any=20 > > data that defines a dialogue. This is in effect a Session Border=20 > > Controller. Some day, the standards bodies will come to=20 > grips with the=20 > > business realities that carriers have, and the desire that=20 > simpler is=20 > > better. > >=20 > > Although I wouldn't propose this to the spearmint group as its not=20 > > really in scope, I just wanted to suggest that we focus on=20 > selection=20 > > of the best proxy with the assumption that it is "nearby" where the=20 > > media should cross. This will work with any solution being proposed=20 > > (ETSI TISPAN/MSF/IETF). > > Seems reasonable. > >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Saturday, November 11, 2006 3:34 PM > > To: Patrick Melampy; Michael Haberler; Reinaldo Penno > > Cc: speermint@ietf.org; Uzelac, Adam > > Subject: RE: [Speermint] Source-based routing > >=20 > > Chasing down this thread. > >=20 > > In general, I think that intertwining the signaling point entry and=20 > > media point entry might be a mistake. I would prefer to keep these=20 > > decisions decoupled. What do you do if the media location=20 > is unknown=20 > > at initial setup time, but perhaps known later in the flow?=20 > What do=20 > > you do if the media location changes during the call setup?=20 > What if=20 > > the media crossing point is from one access network, but=20 > the signaling=20 > > crossing point is from the home provider? > >=20 > > Maybe it won't make a difference, but creating such=20 > constraints seems=20 > > to make the solution more brittle. > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > Sent: Thursday, November 09, 2006 2:21 PM > > > To: 'Michael Haberler'; 'Reinaldo Penno' > > > Cc: speermint@ietf.org; 'Uzelac, Adam' > > > Subject: RE: [Speermint] Source-based routing > > >=20 > > > The real issue here affects signaling and media. It appears > > to me that > > > the correct algorithm to use would be based on the offered > > addresses > > > in the SDP, and which border signaling point is closest.=20 > > The reasons > > > for this are: > > >=20 > > > 1.) The signaling originator may not be co-located with the > > source of > > > media. > > > This is often the case with Softswitch/Media Gateway sources of=20 > > > traffic. Its also like to be true with Softswitch Based endpoints > > > (MGCP/NCS) where the call controller is centrally=20 > located, but the=20 > > > endpoints are widely distributed. > > >=20 > > > 2.) The signaling crossing point that is closes to the > > source of the > > > media provides a "best crossing point" for the media as well. > > >=20 > > > Although I've resisted talking about the media --- its truly=20 > > > important. The location of the media crossing point, and > > the control > > > of the media, are as important as any other aspect in peering. > > >=20 > > > There are some that would suggest the signaling crossing=20 > points and=20 > > > media crossing points are un-related. But to subsequently setup,=20 > > > manage, and control the media with a middle box requires the same=20 > > > determination of the best media crossing point. The=20 > mechanisms for=20 > > > doing this "locate the best middle box" are weak at best. > > Some say use > > > a policy server. However none of the policy server > > interfaces I have > > > seen proposed by ETSI TISPAN, 3GPP, seem to include a "source ip=20 > > > address" in the request to help choose a destination ip > > address. While > > > out of the scope of this working group, one should consider the=20 > > > utility of the following suggestion. > > >=20 > > > I propose that the best signaling crossing point be > > determined based > > > on the source of the media. This would provide for a > > defined crossing > > > point that then could manage the media flows by association. > > >=20 > > > -----Original Message----- > > > From: Michael Haberler [mailto:mah@inode.at] > > > Sent: Thursday, November 09, 2006 2:38 AM > > > To: Reinaldo Penno > > > Cc: speermint@ietf.org; Uzelac, Adam > > > Subject: Re: [Speermint] Source-based routing > > >=20 > > > Reinaldo Penno schrieb: > > > > I guess the problem statement is: > > > > > > > > For a certain call, how to I find the most appropriate > > > egress/ingree > > > > peering point? > > > > =20 > > >=20 > > > I'm not sure wether that was what Adam meant - need to clarify > > >=20 > > > I see two interpretations: > > > - topological optimization of next hop (IP adress, distance..) > > > - a parameter into policy application - for resolution > > services which > > > might give different answers to different originators > > >=20 > > >=20 > > >=20 > > > -Michael > > >=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 > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat Nov 11 17:11:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj13Y-0003d6-3G; Sat, 11 Nov 2006 17:10:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj13X-0003d1-1K for speermint@ietf.org; Sat, 11 Nov 2006 17:10:31 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj13W-0003yN-17 for speermint@ietf.org; Sat, 11 Nov 2006 17:10:31 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 11 Nov 2006 14:07:35 -0800 X-IronPort-AV: i="4.09,413,1157353200"; d="scan'208"; a="608185749:sNHT44552752" 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] Source-based routing Date: Sat, 11 Nov 2006 17:10:23 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280624F532@proton.jnpr.net> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3022DB44B@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing Thread-index: AccD0mSmx/4W053JRWSZEtSRwjXmOAAHaingABMMp6YAAHkNoABkvpagAAL2IhA= From: "Reinaldo Penno" To: "Michael Hammer \(mhammer\)" , "Shawn Pouliotte" , "Patrick Melampy" , "Michael Haberler" X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: speermint@ietf.org, "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 Hello Mike, As I said later in the thread from a layer 3 perspective (pure routing) that might not be optimal, but maybe optimal from a media services or business perspective. So, it can go both ways. =20 In the IETF cases were presented where media egress was controlled by media relay based on who as sending the INVITE and location. Regards, Reinaldo > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 > Sent: Saturday, November 11, 2006 12:37 PM > To: Reinaldo Penno; Shawn Pouliotte; Patrick Melampy; Michael Haberler > Cc: speermint@ietf.org; Uzelac, Adam > Subject: RE: [Speermint] Source-based routing >=20 > So, the media now follows a non-optimal path? >=20 > Mike > =20 >=20 > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Thursday, November 09, 2006 3:36 PM > > To: Shawn Pouliotte; Patrick Melampy; Michael Haberler > > Cc: speermint@ietf.org; Uzelac, Adam > > Subject: RE: [Speermint] Source-based routing > >=20 > > Hello Shawn, > >=20 > > the reverse is also true. If you _do not_ have a collapsed peering=20 > > scheme (signaling and media crossing at the same point=20 > through media=20 > > anchoring), chances are media is going to follow layer 3=20 > routing and=20 > > signaling Layer 5 (route headers, outbound proxy, etc,=20 > etc). And they=20 > > might in fact go to two different completely locations. > >=20 > > So, maybe what you actually like is for media to follow signaling=20 > > after you discover the "best" (whatever that means)=20 > signaling crossing=20 > > point. > >=20 > > Regards, > >=20 > > Reinaldo > >=20 > > > -----Original Message----- > > > From: Shawn Pouliotte [mailto:Shawn.Pouliotte@nominum.com] > > > Sent: Thursday, November 09, 2006 12:19 PM > > > To: Patrick Melampy; 'Michael Haberler'; Reinaldo Penno > > > Cc: speermint@ietf.org; 'Uzelac, Adam' > > > Subject: Re: [Speermint] Source-based routing > > >=20 > > > I think the biggest question for me is what is important at the=20 > > > peering point - there are a lot of things that could > > theoretically be > > > signaled but what is important? You are trying to decide > > if, how and > > > where to admit traffic into a network. > > >=20 > > >=20 > > > For this chain, yes, I was thinking about a collapsed BG=20 > model. You=20 > > > are alluding to a mid-com model as I read it. I only know > > of 1 vendor > > > offering > > > H.248 controlled ip to ip gateways and they are not seeing much=20 > > > success. I know of one other vendor that is developing in > > this area.=20 > > > The general driver for this as I understood was > > streamlining resources > > > by splitting signaling and media, offering a better=20 > scaling model,=20 > > > better resource selection model, and h/a model. That said, > > I have not > > > run into anyone that actually wanted media path in a vastly > > different > > > geography from signaling. Nothing would preclude it. I am > > curious to > > > hear thoughts from the carrier representatives on the list. > > >=20 > > > So, with all that I certainly don't disagree that source based=20 > > > parameters play a role in route selection. When the group makes=20 > > > recommendations on those, we should understand the use > > cases and why > > > they are important (in a deployable network). > > >=20 > > > Shawn > > >=20 > > >=20 > > > On 11/9/06 11:20 AM, "Patrick Melampy"=20 > > > wrote: > > >=20 > > > > The real issue here affects signaling and media. It appears > > > to me that > > > > the correct algorithm to use would be based on the offered > > > addresses > > > > in the SDP, and which border signaling point is closest.=20 > > > The reasons for this are: > > > >=20 > > > > 1.) The signaling originator may not be co-located with the > > > source of media. > > > > This is often the case with Softswitch/Media Gateway sources of=20 > > > > traffic. Its also like to be true with Softswitch Based=20 > endpoints > > > > (MGCP/NCS) where the call controller is centrally > > located, but the > > > > endpoints are widely distributed. > > > >=20 > > > > 2.) The signaling crossing point that is closes to the > > > source of the > > > > media provides a "best crossing point" for the media as well. > > > >=20 > > > > Although I've resisted talking about the media --- its truly=20 > > > > important. The location of the media crossing point, and > > > the control > > > > of the media, are as important as any other aspect in peering. > > > >=20 > > > > There are some that would suggest the signaling crossing > > points and > > > > media crossing points are un-related. But to=20 > subsequently setup,=20 > > > > manage, and control the media with a middle box=20 > requires the same=20 > > > > determination of the best media crossing point. The > > mechanisms for > > > > doing this "locate the best middle box" are weak at best. > > > Some say use > > > > a policy server. However none of the policy server > > > interfaces I have > > > > seen proposed by ETSI TISPAN, 3GPP, seem to include a=20 > "source ip=20 > > > > address" in the request to help choose a destination ip > > > address. While > > > > out of the scope of this working group, one should consider > > > the utility of the following suggestion. > > > >=20 > > > > I propose that the best signaling crossing point be > > > determined based > > > > on the source of the media. This would provide for a > > > defined crossing > > > > point that then could manage the media flows by association. > > > >=20 > > > > -----Original Message----- > > > > From: Michael Haberler [mailto:mah@inode.at] > > > > Sent: Thursday, November 09, 2006 2:38 AM > > > > To: Reinaldo Penno > > > > Cc: speermint@ietf.org; Uzelac, Adam > > > > Subject: Re: [Speermint] Source-based routing > > > >=20 > > > > Reinaldo Penno schrieb: > > > >> I guess the problem statement is: > > > >>=20 > > > >> For a certain call, how to I find the most appropriate > > > egress/ingree > > > >> peering point? > > > >> =20 > > > >=20 > > > > I'm not sure wether that was what Adam meant - need to clarify > > > >=20 > > > > I see two interpretations: > > > > - topological optimization of next hop (IP adress, distance..) > > > > - a parameter into policy application - for resolution > > > services which > > > > might give different answers to different originators > > > >=20 > > > >=20 > > > >=20 > > > > -Michael > > > >=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 > > >=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 Sat Nov 11 18:20:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj28O-0000gj-Dm; Sat, 11 Nov 2006 18:19:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj28N-0000ei-5a for speermint@ietf.org; Sat, 11 Nov 2006 18:19:35 -0500 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj28L-0004ZA-TC for speermint@ietf.org; Sat, 11 Nov 2006 18:19:35 -0500 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Sat, 11 Nov 2006 18:18:58 -0500 id 0158812D.45565A62.000067CB In-Reply-To: <02a801c705d5$b6f30020$800101df@acmepacket.com> References: <02a801c705d5$b6f30020$800101df@acmepacket.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Speermint] Source-based routing Date: Sat, 11 Nov 2006 18:19:03 -0500 To: Patrick Melampy X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Nov 11, 2006, at 4:09 PM, Patrick Melampy wrote: > We both have many proxies -- lets just say 100. > > We both want to run our networks independently.... > a.) Add new proxies > b.) Service proxies > c.) remove proxies > > What is important for this standard body is to define protocols and > BCPs > that will let carriers communicate the aspects of adjacency that are > necessary -- no more. > > I would suggest minimally we need to exchange lists of proxies All of this can be done with the already defined SRV and NAPTR mechanism. I don't see a need to invent something new here. As I suggested before, the SRV/NAPTR BCP should explain how to: 1) add new proxies 2) service proxies 3) remove proxies > I would also suggest we might improve our efficiencies of routing > if we also > exchanged some attributes based on our service level agreement > a.) Rates and speeds > b.) volumes by location Ok. You can't do that in NAPTR or SRV records, but I suspect it is much better to be in a contract than anyplace else. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat Nov 11 23:04:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj6Ys-0005f8-1K; Sat, 11 Nov 2006 23:03:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj6Yq-0005ez-6k for speermint@ietf.org; Sat, 11 Nov 2006 23:03:12 -0500 Received: from omzesmtp02.mci.com ([199.249.17.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj6Yn-0002lB-HG for speermint@ietf.org; Sat, 11 Nov 2006 23:03:12 -0500 Received: from pmismtp03.mcilink.com ([166.38.62.38]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0J8L0051QN925C@firewall.mci.com> for speermint@ietf.org; Sun, 12 Nov 2006 04:03:03 +0000 (GMT) Received: from pmismtp03.mcilink.com ([127.0.0.1]) by pmismtp03.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0J8L00E6QN92I3@pmismtp03.mcilink.com> for speermint@ietf.org; Sun, 12 Nov 2006 04:03:02 +0000 (GMT) Received: from ASHSRV141.mcilink.com ([153.39.68.167]) by pmismtp03.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0J8L00E1HN92I4@pmismtp03.mcilink.com> for speermint@ietf.org; Sun, 12 Nov 2006 04:03:02 +0000 (GMT) Received: from ASHEVS010.mcilink.com ([153.39.69.145]) by ASHSRV141.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Nov 2006 04:03:02 +0000 Date: Sun, 12 Nov 2006 04:01:56 +0000 From: "Dwight, Timothy M (Tim)" Subject: RE: [Speermint] Source-based routing In-reply-to: <02a801c705d5$b6f30020$800101df@acmepacket.com> To: Patrick Melampy , "Michael Hammer (mhammer)" , speermint@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Content-class: urn:content-classes:message Thread-topic: [Speermint] Source-based routing Thread-index: AccD0mSmx/4W053JRWSZEtSRwjXmOAAHaingAHfYOkAAAHPTsAAAbhKAAAAaClAADpW5MA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 12 Nov 2006 04:03:02.0099 (UTC) FILETIME=[72A43A30:01C7060F] 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'm not sure about item #1 ("I would want my proxies logically paired with the proxies on the other side."). In networks with which I am familiar, L5 peering devices are not generally collocated nor do 1-to-1 relationships between them, exist. Tim p.s. I'm not an operator but I work for one. Not that that should give my comments any more (or less) significance. > -----Original Message----- > From: Patrick Melampy [mailto:PMelampy@acmepacket.com]=20 > Sent: Saturday, November 11, 2006 3:10 PM > To: 'Michael Hammer (mhammer)'; speermint@ietf.org > Subject: RE: [Speermint] Source-based routing >=20 > Forgetting media for now -- >=20 > But what we need to focus on..... >=20 > Imagine you run a network....and so do I >=20 > We both have many proxies -- lets just say 100. >=20 > We both want to run our networks independently.... > a.) Add new proxies > b.) Service proxies > c.) remove proxies >=20 > What is important for this standard body is to define=20 > protocols and BCPs that will let carriers communicate the=20 > aspects of adjacency that are necessary -- no more. >=20 > I would suggest minimally we need to exchange lists of=20 > proxies I would also suggest we might improve our=20 > efficiencies of routing if we also exchanged some attributes=20 > based on our service level agreement > a.) Rates and speeds > b.) volumes by location >=20 > The question is...are all proxies equal? Should the call=20 > originating side care which destination side proxy is chosen?=20 > Should it be consistent if possible? Is there benefit to=20 > having it controllable and definable?=20 >=20 > If I were a carrier, I would want the following > 1.) I would want my proxies logically paired with the proxies=20 > on the other side. This would improve detection of service=20 > impairments and route-around logic. It would also be easier=20 > to debug and maintain. > 2.) I would want secondary proxies for backup on both sides.=20 > 3.) I would want to know what the "offered capacity" the=20 > destination proxy is offering to me for my use. This includes=20 > counts of calls, and kilobytes of media. >=20 > It seems to me that selection of a proxy on the "local" side=20 > would then be logically selecting a proxy on the "far" side.=20 > This is actually congruent with what ETSI TISPAN and MSF are=20 > proposing for their Peering Edges between carriers. Both=20 > sides would have a proxy specifically used for Peering. So=20 > the logic for selecting a crossing point is all local to each network. >=20 > So maybe it is truly out of scope if we can agree that there=20 > are edge proxies that establish a real or logical "pairing"=20 > at peering borders? >=20 > Is this reasonable? Or am I once again smoking crack. >=20 >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Saturday, November 11, 2006 3:51 PM > To: Patrick Melampy; Michael Haberler; Reinaldo Penno > Cc: Uzelac, Adam > Subject: RE: [Speermint] Source-based routing : PRIVATE >=20 > This may really be an implementation detail that does not=20 > need standardization. >=20 > Mike > =20 >=20 > > -----Original Message----- > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > Sent: Saturday, November 11, 2006 3:46 PM > > To: Michael Hammer (mhammer); 'Michael Haberler'; 'Reinaldo Penno' > > Cc: 'Uzelac, Adam' > > Subject: RE: [Speermint] Source-based routing : PRIVATE > >=20 > > Your of course correct. In an ideal world, we would just let the=20 > > source and destination stream packets directly to each=20 > other. However,=20 > > there may be a desire to use a middle box of some kind for business=20 > > and security reasons. > > If one is to use a middle box or media relay, the algorithm for=20 > > selecting one (when there are many possible) is very difficult. > >=20 > > In the ETSI TISPAN and MSF groups, they are proposing a=20 > "policy" layer=20 > > between the signaling layer, and the media relays. This=20 > policy layer=20 > > would in theory be able to "figure out" where the best=20 > media location=20 > > is. I find this mechanism horrible for the reasons you=20 > suggest. Lots=20 > > of spread out state, that can easily get screwed up with=20 > complex call=20 > > flows. > >=20 > > It might be heresy to suggest this....but a Transparent B2BUA that=20 > > also transparently manages the MEDIA could be very effective and=20 > > simple. Lets define transparency as a device that does not=20 > modify any=20 > > data that defines a dialogue. This is in effect a Session Border=20 > > Controller. Some day, the standards bodies will come to=20 > grips with the=20 > > business realities that carriers have, and the desire that=20 > simpler is=20 > > better. > >=20 > > Although I wouldn't propose this to the spearmint group as its not=20 > > really in scope, I just wanted to suggest that we focus on=20 > selection=20 > > of the best proxy with the assumption that it is "nearby" where the=20 > > media should cross. This will work with any solution being proposed=20 > > (ETSI TISPAN/MSF/IETF). > > Seems reasonable. > >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Saturday, November 11, 2006 3:34 PM > > To: Patrick Melampy; Michael Haberler; Reinaldo Penno > > Cc: speermint@ietf.org; Uzelac, Adam > > Subject: RE: [Speermint] Source-based routing > >=20 > > Chasing down this thread. > >=20 > > In general, I think that intertwining the signaling point entry and=20 > > media point entry might be a mistake. I would prefer to keep these=20 > > decisions decoupled. What do you do if the media location=20 > is unknown=20 > > at initial setup time, but perhaps known later in the flow?=20 > What do=20 > > you do if the media location changes during the call setup?=20 > What if=20 > > the media crossing point is from one access network, but=20 > the signaling=20 > > crossing point is from the home provider? > >=20 > > Maybe it won't make a difference, but creating such=20 > constraints seems=20 > > to make the solution more brittle. > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > Sent: Thursday, November 09, 2006 2:21 PM > > > To: 'Michael Haberler'; 'Reinaldo Penno' > > > Cc: speermint@ietf.org; 'Uzelac, Adam' > > > Subject: RE: [Speermint] Source-based routing > > >=20 > > > The real issue here affects signaling and media. It appears > > to me that > > > the correct algorithm to use would be based on the offered > > addresses > > > in the SDP, and which border signaling point is closest.=20 > > The reasons > > > for this are: > > >=20 > > > 1.) The signaling originator may not be co-located with the > > source of > > > media. > > > This is often the case with Softswitch/Media Gateway sources of=20 > > > traffic. Its also like to be true with Softswitch Based endpoints > > > (MGCP/NCS) where the call controller is centrally=20 > located, but the=20 > > > endpoints are widely distributed. > > >=20 > > > 2.) The signaling crossing point that is closes to the > > source of the > > > media provides a "best crossing point" for the media as well. > > >=20 > > > Although I've resisted talking about the media --- its truly=20 > > > important. The location of the media crossing point, and > > the control > > > of the media, are as important as any other aspect in peering. > > >=20 > > > There are some that would suggest the signaling crossing=20 > points and=20 > > > media crossing points are un-related. But to subsequently setup,=20 > > > manage, and control the media with a middle box requires the same=20 > > > determination of the best media crossing point. The=20 > mechanisms for=20 > > > doing this "locate the best middle box" are weak at best. > > Some say use > > > a policy server. However none of the policy server > > interfaces I have > > > seen proposed by ETSI TISPAN, 3GPP, seem to include a "source ip=20 > > > address" in the request to help choose a destination ip > > address. While > > > out of the scope of this working group, one should consider the=20 > > > utility of the following suggestion. > > >=20 > > > I propose that the best signaling crossing point be > > determined based > > > on the source of the media. This would provide for a > > defined crossing > > > point that then could manage the media flows by association. > > >=20 > > > -----Original Message----- > > > From: Michael Haberler [mailto:mah@inode.at] > > > Sent: Thursday, November 09, 2006 2:38 AM > > > To: Reinaldo Penno > > > Cc: speermint@ietf.org; Uzelac, Adam > > > Subject: Re: [Speermint] Source-based routing > > >=20 > > > Reinaldo Penno schrieb: > > > > I guess the problem statement is: > > > > > > > > For a certain call, how to I find the most appropriate > > > egress/ingree > > > > peering point? > > > > =20 > > >=20 > > > I'm not sure wether that was what Adam meant - need to clarify > > >=20 > > > I see two interpretations: > > > - topological optimization of next hop (IP adress, distance..) > > > - a parameter into policy application - for resolution > > services which > > > might give different answers to different originators > > >=20 > > >=20 > > >=20 > > > -Michael > > >=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 > >=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 Sun Nov 12 19:53:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjQ3H-0003kk-AV; Sun, 12 Nov 2006 19:51:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjQ3G-0003kb-60 for speermint@ietf.org; Sun, 12 Nov 2006 19:51:54 -0500 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjQ3D-0008HT-KT for speermint@ietf.org; Sun, 12 Nov 2006 19:51:54 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id kAD0pmPn241646 for ; Mon, 13 Nov 2006 00:51:48 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAD0t0ai2445386 for ; Mon, 13 Nov 2006 01:55:00 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAD0pmOP031780 for ; Mon, 13 Nov 2006 01:51:48 +0100 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAD0pmQU031777; Mon, 13 Nov 2006 01:51:48 +0100 In-Reply-To: To: "Uzelac, Adam" MIME-Version: 1.0 Subject: Re: [Speermint] Charter clarification X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Avshalom Houri Message-ID: Date: Mon, 13 Nov 2006 02:54:56 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.5HF607 | June 26, 2006) at 13/11/2006 02:54:59, Serialize complete at 13/11/2006 02:54:59 X-Spam-Score: 0.5 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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: , Content-Type: multipart/mixed; boundary="===============2008982679==" Errors-To: speermint-bounces@ietf.org This is a multipart message in MIME format. --===============2008982679== Content-Type: multipart/alternative; boundary="=_alternative 00008D04C2257225_=" This is a multipart message in MIME format. --=_alternative 00008D04C2257225_= Content-Type: text/plain; charset="US-ASCII" Yes. I also remember the discussion in one of the speermint bofs where we explicitly that we are talking about any session and this is why Jonathan suggested the name SPEER for Session Peering. Sometimes things need to be reiterate make them more consciously accepted... --Avshalom Real Time Collaboration Standards "Uzelac, Adam" wrote on 09/11/2006 01:55:42: > I would like to be sure that I understand correctly the sentiment about > Presence/IM being part of the charter: > > >From the charter: > SPEERMINT focuses architectures to identify, signal, and route > delay-sensitive (real-time) communication sessions. These sessions > use the SIP signaling protocol to enable peering between two or more > administrative domains over IP networks. Where these domains peer, > or meet, the establishment of trust, security, and a resistance to > abuse and attack are all important considerations. > > Outside of possibly concluding that Presence isn't really a "real-time" > communication, but rather status, I believe that the charter doesn't > really need to change. IM and Presence should be considered in scope. > > -AU > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint --=_alternative 00008D04C2257225_= Content-Type: text/html; charset="US-ASCII"
Yes. I also remember the discussion in one of the speermint bofs where
we explicitly that we are talking about any session and this is why
Jonathan suggested the name SPEER for Session Peering.

Sometimes things need to be reiterate make them more consciously
accepted...

--Avshalom
Real Time Collaboration Standards

"Uzelac, Adam" <Adam.Uzelac@globalcrossing.com> wrote on 09/11/2006 01:55:42:

> I would like to be sure that I understand correctly the sentiment about
> Presence/IM being part of the charter:
>
> >From the charter:
> SPEERMINT focuses architectures to identify, signal, and route
> delay-sensitive (real-time) communication sessions. These sessions
> use the SIP signaling protocol to enable peering between two or more
> administrative domains over IP networks. Where these domains peer,
> or meet, the establishment of trust, security, and a resistance to
> abuse and attack are all important considerations.
>
> Outside of possibly concluding that Presence isn't really a "real-time"
> communication, but rather status, I believe that the charter doesn't
> really need to change.  IM and Presence should be considered in scope.
>
> -AU
>
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint
 --=_alternative 00008D04C2257225_=-- --===============2008982679== 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 --===============2008982679==-- From speermint-bounces@ietf.org Sun Nov 12 22:01:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjS48-0003GW-RL; Sun, 12 Nov 2006 22:00:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjS47-0003GO-16 for speermint@ietf.org; Sun, 12 Nov 2006 22:00:55 -0500 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 1GjS45-00023A-QJ for speermint@ietf.org; Sun, 12 Nov 2006 22:00:55 -0500 Received: from hkaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.10) id AFE002F8; Sun, 12 Nov 2006 22:00:48 -0500 From: "Hadriel Kaplan" To: "'Michael Hammer \(mhammer\)'" Subject: RE: [Speermint] Source-based routing Date: Sun, 12 Nov 2006 22:00:09 -0500 Message-ID: <022401c706cf$d49fd530$0500a8c0@acmepacket.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: <072C5B76F7CEAB488172C6F64B30B5E3022DB44B@xmb-rtp-20b.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccD0mSmx/4W053JRWSZEtSRwjXmOAAHaingABMMp6YAAHkNoABkvpagAD8+8hA= X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 don't mean to jump in on this thread's ultimate topic, but in reference to the statement below, you and I and the UA's have no idea what the optimal path is. It is NOT necessarily the BGP/IGP path, for example. As you well know, BGP/IGP do not determine/create the optimal path for latency, jitter, nor even bandwidth. The border element path may be more optimal, the same, or less. The only one who could know the optimal path is the network operator. Whether they do know it or not, and whether they take advantage of it, depends on them and their network design. -hadriel > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Saturday, November 11, 2006 3:37 PM > To: Reinaldo Penno; Shawn Pouliotte; Patrick Melampy; Michael Haberler > Cc: speermint@ietf.org; Uzelac, Adam > Subject: RE: [Speermint] Source-based routing > > So, the media now follows a non-optimal path? > > Mike > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Nov 13 06:01:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjZYi-0007i2-N5; Mon, 13 Nov 2006 06:01:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjZYi-0007hv-0A for speermint@ietf.org; Mon, 13 Nov 2006 06:01:00 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GjZYc-0008F8-GN for speermint@ietf.org; Mon, 13 Nov 2006 06:00:59 -0500 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] Source-based routing Date: Mon, 13 Nov 2006 12:00:05 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4C0D@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing thread-index: AccD0mSmx/4W053JRWSZEtSRwjXmOAAHaingABMMp6YAAHkNoABkvpagAD8+8hAAEP0+xA== References: <022401c706cf$d49fd530$0500a8c0@acmepacket.com> From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 Simple question =20 Regarding source based routing and what "close" means, do we really want to be involved in this discussion: http://potaroo.net/ispcol/2006-11/raw.html = =20 =20 or leave this to other people and groups? =20 Richard _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Nov 13 10:00:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjdI0-0008A1-2l; Mon, 13 Nov 2006 10:00:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjdHy-00089u-O4 for speermint@ietf.org; Mon, 13 Nov 2006 09:59:58 -0500 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GjdHx-0006Zw-BO for speermint@ietf.org; Mon, 13 Nov 2006 09:59:58 -0500 Received: from source ([192.150.20.142]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Mon, 13 Nov 2006 06:59:54 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id kADF0BIY018000; Mon, 13 Nov 2006 07:00:11 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id kADExeeA020685; Mon, 13 Nov 2006 06:59:51 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 06:59:40 -0800 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] Source-based routing Date: Mon, 13 Nov 2006 06:59:34 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22141309@namail5.corp.adobe.com> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4C0D@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing Thread-Index: AccD0mSmx/4W053JRWSZEtSRwjXmOAAHaingABMMp6YAAHkNoABkvpagAD8+8hAAEP0+xAAH2yBQ From: "Henry Sinnreich" To: "Stastny Richard" , X-OriginalArrivalTime: 13 Nov 2006 14:59:40.0217 (UTC) FILETIME=[5829B290:01C70734] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Stastny Richard writes: > Regarding source based routing and what "close" means,=20 > do we really want to be involved in this discussion This is an excellent question and points to the fact that we don't have in SIP any reasonably simple routing protocols, such as exist in IP. Instead of a routing protocol, at this point in time there is a big list of RFCs and I-Ds with countless rules that keep changing and that only very few implementers could have the expertise to follow - assuming there was agreement on all the rules, which isn't. Provisioned SBCs seem to rule in interdomain routing instead. The complexity of SIP routing makes also multi-vendor interoperability rather unlikely in infrastructure based VoIP networks. If there is to be a SIP routing protocol, it must be simple as stated in the papers quoted here below. This is the reason why P2P SIP (which has clear cut routing protocols) and the simple trapezoid model for interdomain SIP routing make more sense IMHO. True SIP routing protocols beyond the trapezoid model may be better developed however in the SIP WG. Thanks, Henry -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Monday, November 13, 2006 5:00 AM To: speermint@ietf.org Subject: Re: [Speermint] Source-based routing Simple question =20 Regarding source based routing and what "close" means, do we really want to be involved in this discussion: http://potaroo.net/ispcol/2006-11/raw.html =20 =20 or leave this to other people and groups? =20 Richard _______________________________________________ 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 Nov 13 12:20:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjfTY-0004Hn-Bd; Mon, 13 Nov 2006 12:20:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjfTX-0004HV-MI for speermint@ietf.org; Mon, 13 Nov 2006 12:20:03 -0500 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjfTW-0000x8-4p for speermint@ietf.org; Mon, 13 Nov 2006 12:20:03 -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] Source-based routing Date: Mon, 13 Nov 2006 12:19:43 -0500 Message-ID: <45AEC6EF95942140888406588E1A66025ABCE3@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing Thread-Index: AccD0mSmx/4W053JRWSZEtSRwjXmOAAHaingABHXpJAAALFfsADDYyoQ From: "Livingood, Jason" To: "Uzelac, Adam" , "Reinaldo Penno" , "Patrick Melampy" , "Michael Haberler" X-OriginalArrivalTime: 13 Nov 2006 17:19:43.0978 (UTC) FILETIME=[E931DCA0:01C70747] X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 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 Yes getting 2-way media is in scope. Seeing as how you cannot really have a meaningful multimedia session with media working, I'd say this is perhaps stating the obvious. ;-) Jason=20 > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 > Sent: Thursday, November 09, 2006 3:11 PM > To: Reinaldo Penno; Patrick Melampy; Michael Haberler > Cc: speermint@ietf.org > Subject: RE: [Speermint] Source-based routing >=20 > Is there consensus around the notion that media=20 > considerations are in scope of SPEERMINT? It's not always=20 > the case, but it should be a consideration when determining=20 > next-hops route responses to a location function look-up. I=20 > would like to point out that this becomes very difficult in=20 > ENUM/DNS next-hop determinations. Hence the existence of the=20 > INVITE/3XX next-hop determination method. >=20 > -AU >=20 > PS - please read "media considerations" as _NOT_ meaning=20 > exclusively CODECs.=20 >=20 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Thursday, November 09, 2006 11:56 AM > To: Patrick Melampy; Michael Haberler > Cc: speermint@ietf.org; Uzelac, Adam > Subject: RE: [Speermint] Source-based routing >=20 > As I side note I mentioned in the IETF meeting that we keep=20 > pushing media aside and only talking about signaling but what=20 > mostly matters in terms of user experience is the media. So,=20 > I agree with you that media is important. >=20 > About your suggestion below, that's a nice insight, but it is=20 > still not clear to me how from the source IP address the=20 > proxy finds the notion of "distance". Of course the first=20 > peering proxy that receives the signaling can look at number=20 > of Vias or TTL or others. But how would this proxy find out=20 > the distance between the endpoint and other peering proxies=20 > in order to send a correct 302, for instance?=20 >=20 > So, the "default" peering proxy can try to find that out=20 > (even if consulting some external DB) or the endpoint could=20 > try itself. The endpoint could send OPTION messages with=20 > increasing Max-Forwards to a coupld of proxies, or some other=20 > funky method. >=20 > Thanks, >=20 > Reinaldo >=20 > =20 >=20 > > -----Original Message----- > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > Sent: Thursday, November 09, 2006 11:21 AM > > To: 'Michael Haberler'; Reinaldo Penno > > Cc: speermint@ietf.org; 'Uzelac, Adam' > > Subject: RE: [Speermint] Source-based routing > >=20 > > The real issue here affects signaling and media. It appears=20 > to me that >=20 > > the correct algorithm to use would be based on the offered=20 > addresses=20 > > in the SDP, and which border signaling point is closest.=20 > The reasons=20 > > for this are: > >=20 > > 1.) The signaling originator may not be co-located with the=20 > source of=20 > > media. > > This is often the case with Softswitch/Media Gateway sources of=20 > > traffic. Its also like to be true with Softswitch Based endpoints > > (MGCP/NCS) where the call controller is centrally located, but the=20 > > endpoints are widely distributed. > >=20 > > 2.) The signaling crossing point that is closes to the=20 > source of the=20 > > media provides a "best crossing point" for the media as well. > >=20 > > Although I've resisted talking about the media --- its truly=20 > > important. The location of the media crossing point, and=20 > the control=20 > > of the media, are as important as any other aspect in peering. > >=20 > > There are some that would suggest the signaling crossing points and=20 > > media crossing points are un-related. But to subsequently setup,=20 > > manage, and control the media with a middle box requires the same=20 > > determination of the best media crossing point. The mechanisms for=20 > > doing this "locate the best middle box" are weak at best.=20 > Some say use >=20 > > a policy server. However none of the policy server=20 > interfaces I have=20 > > seen proposed by ETSI TISPAN, 3GPP, seem to include a "source ip=20 > > address" in the request to help choose a destination ip=20 > address. While >=20 > > out of the scope of this working group, one should consider the=20 > > utility of the following suggestion. > >=20 > > I propose that the best signaling crossing point be=20 > determined based=20 > > on the source of the media. This would provide for a=20 > defined crossing=20 > > point that then could manage the media flows by association. > >=20 > > -----Original Message----- > > From: Michael Haberler [mailto:mah@inode.at] > > Sent: Thursday, November 09, 2006 2:38 AM > > To: Reinaldo Penno > > Cc: speermint@ietf.org; Uzelac, Adam > > Subject: Re: [Speermint] Source-based routing > >=20 > > Reinaldo Penno schrieb: > > > I guess the problem statement is: > > > > > > For a certain call, how to I find the most appropriate > > egress/ingree > > > peering point? > > > =20 > >=20 > > I'm not sure wether that was what Adam meant - need to clarify > >=20 > > I see two interpretations: > > - topological optimization of next hop (IP adress, distance..) > > - a parameter into policy application - for resolution=20 > services which=20 > > might give different answers to different originators > >=20 > >=20 > >=20 > > -Michael > >=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 Mon Nov 13 12:22:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjfVt-0005qO-05; Mon, 13 Nov 2006 12:22:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjfVr-0005pm-Id for speermint@ietf.org; Mon, 13 Nov 2006 12:22:27 -0500 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 1GjfVn-0001Im-1r for speermint@ietf.org; Mon, 13 Nov 2006 12:22:27 -0500 Received: from ([10.52.116.10]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.27565433; Mon, 13 Nov 2006 12:22:03 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 12:22:02 -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] Source-based routing Date: Mon, 13 Nov 2006 12:22:02 -0500 Message-ID: <45AEC6EF95942140888406588E1A66025ABCE4@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Source-based routing Thread-Index: AccD0mSmx/4W053JRWSZEtSRwjXmOAAHaingABHXpJAAALFfsAABBJuSAABxGbAAwf3UUA== From: "Livingood, Jason" To: "Reinaldo Penno" , "Stastny Richard" , "Uzelac, Adam" , "Patrick Melampy" , "Michael Haberler" X-OriginalArrivalTime: 13 Nov 2006 17:22:02.0926 (UTC) FILETIME=[3C03A4E0:01C70748] 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 Excellent find... Perhaps I can observe that we keep asking if stuff is in scope or not and that we spend a lot of time on this and suggest that it is not terribly helpful. Let's keep focusing on developing the documents and work at hand. :-) Jason=20 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 > Sent: Thursday, November 09, 2006 3:46 PM > To: Stastny Richard; Uzelac, Adam; Patrick Melampy; Michael Haberler > Cc: speermint@ietf.org > Subject: RE: [Speermint] Source-based routing >=20 > It is in scope >=20 > "However, in order to achieve real-time Session PEERing, both=20 > signaling and media flows must be taken into consideration.=20 > In addition, the working group recognizes that there will be=20 > use cases that require SPEERMINT to focus on the interaction=20 > between the application layer and lower network layers, or=20 > the dependence of specific application layer use cases on=20 > lower layers, so SPEERMINT will have to be prepared to solve=20 > these problems as they arise." >=20 > Thanks, >=20 > Reinaldo=20 >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, November 09, 2006 12:33 PM > > To: Uzelac, Adam; Reinaldo Penno; Patrick Melampy; Michael Haberler > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Source-based routing > >=20 > > IMO it is in scope, but our first priority is to get a=20 > peering going=20 > > at all > >=20 > > media is only relevant in some use cases and the problems=20 > are not easy=20 > > to resolve. So it should have second priority - it will=20 > also take some=20 > > time to work out the use cases, etc. > > =20 > > Richard > >=20 > > ________________________________ > >=20 > > Von: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > > Gesendet: Do 09.11.2006 21:11 > > An: Reinaldo Penno; Patrick Melampy; Michael Haberler > > Cc: speermint@ietf.org > > Betreff: RE: [Speermint] Source-based routing > >=20 > >=20 > >=20 > > Is there consensus around the notion that media=20 > considerations are in=20 > > scope of SPEERMINT? It's not always the case, but it should be a=20 > > consideration when determining next-hops route responses to=20 > a location=20 > > function look-up. I would like to point out that this becomes very=20 > > difficult in ENUM/DNS next-hop determinations. Hence the=20 > existence of=20 > > the INVITE/3XX next-hop determination method. > >=20 > > -AU > >=20 > > PS - please read "media considerations" as _NOT_ meaning=20 > exclusively=20 > > CODECs. > >=20 > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Thursday, November 09, 2006 11:56 AM > > To: Patrick Melampy; Michael Haberler > > Cc: speermint@ietf.org; Uzelac, Adam > > Subject: RE: [Speermint] Source-based routing > >=20 > > As I side note I mentioned in the IETF meeting that we keep pushing=20 > > media aside and only talking about signaling but what=20 > mostly matters=20 > > in terms of user experience is the media. So, I agree with=20 > you that=20 > > media is important. > >=20 > > About your suggestion below, that's a nice insight, but it is still=20 > > not clear to me how from the source IP address the proxy finds the=20 > > notion of "distance". Of course the first peering proxy=20 > that receives=20 > > the signaling can look at number of Vias or TTL or others. But how=20 > > would this proxy find out the distance between the endpoint=20 > and other=20 > > peering proxies in order to send a correct 302, for instance? > >=20 > > So, the "default" peering proxy can try to find that out (even if=20 > > consulting some external DB) or the endpoint could try itself. The=20 > > endpoint could send OPTION messages with increasing=20 > Max-Forwards to a=20 > > coupld of proxies, or some other funky method. > >=20 > > Thanks, > >=20 > > Reinaldo > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > Sent: Thursday, November 09, 2006 11:21 AM > > > To: 'Michael Haberler'; Reinaldo Penno > > > Cc: speermint@ietf.org; 'Uzelac, Adam' > > > Subject: RE: [Speermint] Source-based routing > > > > > > The real issue here affects signaling and media. It appears > > to me that > >=20 > > > the correct algorithm to use would be based on the offered > > addresses > > > in the SDP, and which border signaling point is closest.=20 > > The reasons > > > for this are: > > > > > > 1.) The signaling originator may not be co-located with the > > source of > > > media. > > > This is often the case with Softswitch/Media Gateway sources of=20 > > > traffic. Its also like to be true with Softswitch Based endpoints > > > (MGCP/NCS) where the call controller is centrally=20 > located, but the=20 > > > endpoints are widely distributed. > > > > > > 2.) The signaling crossing point that is closes to the > > source of the > > > media provides a "best crossing point" for the media as well. > > > > > > Although I've resisted talking about the media --- its truly=20 > > > important. The location of the media crossing point, and > > the control > > > of the media, are as important as any other aspect in peering. > > > > > > There are some that would suggest the signaling crossing=20 > points and=20 > > > media crossing points are un-related. But to subsequently setup,=20 > > > manage, and control the media with a middle box requires the same=20 > > > determination of the best media crossing point. The=20 > mechanisms for=20 > > > doing this "locate the best middle box" are weak at best. > > Some say use > >=20 > > > a policy server. However none of the policy server > > interfaces I have > > > seen proposed by ETSI TISPAN, 3GPP, seem to include a "source ip=20 > > > address" in the request to help choose a destination ip > > address. While > >=20 > > > out of the scope of this working group, one should consider the=20 > > > utility of the following suggestion. > > > > > > I propose that the best signaling crossing point be > > determined based > > > on the source of the media. This would provide for a > > defined crossing > > > point that then could manage the media flows by association. > > > > > > -----Original Message----- > > > From: Michael Haberler [mailto:mah@inode.at] > > > Sent: Thursday, November 09, 2006 2:38 AM > > > To: Reinaldo Penno > > > Cc: speermint@ietf.org; Uzelac, Adam > > > Subject: Re: [Speermint] Source-based routing > > > > > > Reinaldo Penno schrieb: > > > > I guess the problem statement is: > > > > > > > > For a certain call, how to I find the most appropriate > > > egress/ingree > > > > peering point? > > > > =20 > > > > > > I'm not sure wether that was what Adam meant - need to clarify > > > > > > I see two interpretations: > > > - topological optimization of next hop (IP adress, distance..) > > > - a parameter into policy application - for resolution > > services which > > > might give different answers to different originators > > > > > > > > > > > > -Michael > > > > > > _______________________________________________ > > > 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 > _______________________________________________ > 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