From extest-admin@lists.bell-labs.com Sun Sep 1 09:19:37 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19293 for ; Sun, 1 Sep 2002 09:19:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g81DL9215793 for ; Sun, 1 Sep 2002 09:21:09 -0400 Date: Sun, 1 Sep 2002 09:21:09 -0400 Message-Id: <200209011321.g81DL9215793@share.research.bell-labs.com> Subject: lists.bell-labs.com mailing list memberships reminder From: mailman-owner@lists.bell-labs.com To: iptel-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: extest-admin@lists.bell-labs.com Errors-To: extest-admin@lists.bell-labs.com X-BeenThere: extest@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk This is a reminder, sent out once a month, about your lists.bell-labs.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, iptel-request@lists.bell-labs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@lists.bell-labs.com. Thanks! Passwords for iptel-archive@lists.ietf.org: List Password // URL ---- -------- iptel@lists.bell-labs.com nexaew http://lists.bell-labs.com/mailman/options/iptel/iptel-archive%40lists.ietf.org From iptel-admin@lists.bell-labs.com Thu Sep 5 09:17:20 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18228 for ; Thu, 5 Sep 2002 09:17:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g85DHh209370; Thu, 5 Sep 2002 09:17:43 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g85DCW209343 for ; Thu, 5 Sep 2002 09:12:32 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g85DCWhN094287 for ; Thu, 5 Sep 2002 09:12:32 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id C4D274439E; Thu, 5 Sep 2002 09:12:26 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 9B4494439D for ; Thu, 5 Sep 2002 09:12:26 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g85DCPo33825 for ; Thu, 5 Sep 2002 09:12:25 -0400 (EDT) Received: from bom6.vsnl.net.in ([203.197.12.44]) by dusty; Thu Sep 5 09:12:25 EDT 2002 Received: by bom6.vsnl.net.in (Postfix, from userid 60001) id 3908220167; Thu, 5 Sep 2002 18:41:12 +0500 (IST) Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 X-Mailer: MIME-tools 4.102 (Entity 4.114) From: akash2901@vsnl.net To: iptel@lists.bell-labs.com X-Mailer: VSNL, Web based email X-Sender-Ip: 203.197.52.57 Message-Id: <20020905134112.3908220167@bom6.vsnl.net.in> Subject: [IPTEL] Project Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 5 Sep 2002 18:41:12 +0500 (IST) I would first like to introduce myself,I am a final year engg. student of Electronics and telecom branch..My knowledge in software -- C,C++,VB,ASP.NET.. We are required to work on a project for 7-8 months..Can we work on somebody's project in this group related to VoIP.Also whether can we show some good implementation in college..if u can give further ideas as to what we can show the college in presentation if we are a part of your project. Thanks a lot... I hope I hear from you soon, With warm regards, Akash TIlak Choudhari, B.E. Student of Electronics and Telecommunications, Vidyavardini's college of Engineering and technology, Vasai(Mumbai University),INDIA. E-mail:cooldude_atc@yahoo.com,akash2901@vsnl.net Tel:+91 22 8056701\+91 9820155140 (Mobile) _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Sep 5 16:33:58 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05164 for ; Thu, 5 Sep 2002 16:33:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g85KMP211665; Thu, 5 Sep 2002 16:22:25 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g85KHa211628 for ; Thu, 5 Sep 2002 16:17:36 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g85KHahN099046 for ; Thu, 5 Sep 2002 16:17:36 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id CBA2F4439E; Thu, 5 Sep 2002 16:17:30 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id A56F34439D for ; Thu, 5 Sep 2002 16:17:30 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g85KHTk99617 for ; Thu, 5 Sep 2002 16:17:29 -0400 (EDT) Received: from newdev.harvard.edu ([140.247.60.212]) by dusty; Thu Sep 5 16:17:29 EDT 2002 Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id g85KHEfW020444; Thu, 5 Sep 2002 16:17:14 -0400 (EDT) From: Scott Bradner Message-Id: <200209052017.g85KHEfW020444@newdev.harvard.edu> To: iptel@lists.bell-labs.com Cc: fluffy@cisco.com, jdrosen@dynamicsoft.com, mankin@psg.com Subject: [IPTEL] new co chair for the iptel working group Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 5 Sep 2002 16:17:14 -0400 (EDT) this is to announce that Cullen Jennings has agreed to become the co-chair of the iptel working group thanks Cullen Scott _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Sep 6 15:43:29 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18989 for ; Fri, 6 Sep 2002 15:43:29 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g86Jha218574; Fri, 6 Sep 2002 15:43:36 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g86Jfu218559 for ; Fri, 6 Sep 2002 15:41:56 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g86JfuhN009581 for ; Fri, 6 Sep 2002 15:41:56 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 762D24439E; Fri, 6 Sep 2002 15:41:51 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 4FF4C4439D for ; Fri, 6 Sep 2002 15:41:51 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g86Jfno66307 for ; Fri, 6 Sep 2002 15:41:50 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by dusty; Fri Sep 6 15:41:49 EDT 2002 Received: from dynamicsoft.com ([63.113.46.47]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g86JfkYH017866 for ; Fri, 6 Sep 2002 15:41:47 -0400 (EDT) Message-ID: <3D7904F9.4020800@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: list iptel Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPTEL] New name for TRIP-GW Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 06 Sep 2002 15:41:45 -0400 Content-Transfer-Encoding: 7bit Folks, I'd like to propose a name change for the TRIP-GW (aka TRIP-LITE) protocol. The reason is, as written, TRIP-GW is not actually an extension to TRIP. Nor is it a subset of TRIP. It differs in the consolidation process defined in the spec. This process, which allows an LS to keep multiple routes to the same prefix, for example, is not compatible with the decision process of TRIP. Its complementary, to be certain, but thats not the same. If you took a normal TRIP LS and put it in front of a TRIP-GW gateway, it would probably not do the right thing. It would function, I think, but you would not be able to implement the appropriate policies to process the information being generated by the gateways. Do people concur with this view? If so, I would propose that we rename the protocol to the Gateway Registration Protocol (GREP). I think the acronym is neat; the protocol is used to search for a gateway, sort of, so grep (in the unix sense) kind of works. The protocol syntax and semantics remain unchanged. We will simply indicate that large pieces of TRIP are used wholesale by this protocol, referring the user to the appropriate sections of the TRIP spec. Thoughts? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Sep 6 16:20:18 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20274 for ; Fri, 6 Sep 2002 16:20:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g86KDN218792; Fri, 6 Sep 2002 16:13:23 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g86KBS218770 for ; Fri, 6 Sep 2002 16:11:28 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g86KBShN009823 for ; Fri, 6 Sep 2002 16:11:28 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 037194439E; Fri, 6 Sep 2002 16:11:23 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id CEC964439D for ; Fri, 6 Sep 2002 16:11:22 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g86KBLo68783 for ; Fri, 6 Sep 2002 16:11:21 -0400 (EDT) Received: from grimy.research.bell-labs.com ([204.178.16.57]) by dusty; Fri Sep 6 16:11:21 EDT 2002 Received: from almso2.proxy.att.com ([192.128.166.71]) by grimy; Fri Sep 6 16:07:34 EDT 2002 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g86HwfG1029103 for ; Fri, 6 Sep 2002 16:09:21 -0400 (EDT) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.019) id 3CE519BE031E0041; Fri, 6 Sep 2002 16:09:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [IPTEL] New name for TRIP-GW Message-ID: <62DA45D4963FA747BA1B253E266760F903BAA374@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [IPTEL] New name for TRIP-GW Thread-Index: AcJV326Q9qfpYIIBQ760bP4zELD7UwAATK/g From: "Roy, Radhika R, ALASO" To: "Jonathan Rosenberg" , "list iptel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by share.research.bell-labs.com id g86KBT218771 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 6 Sep 2002 16:09:20 -0400 Content-Transfer-Encoding: 8bit I believe that the Gateway Registration Protocol (GREP) is too broad a term. In fact, this registration protocol is only applicable for the PSTN-IP Telephony GWs for registration of the routable telephone numbers. So, I propose the name as follows: "Telephony Gateway Registration Protocol (TGRP)" Thanks, Radhika R. Roy AT&T -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Friday, September 06, 2002 3:42 PM To: list iptel Subject: [IPTEL] New name for TRIP-GW Folks, I'd like to propose a name change for the TRIP-GW (aka TRIP-LITE) protocol. The reason is, as written, TRIP-GW is not actually an extension to TRIP. Nor is it a subset of TRIP. It differs in the consolidation process defined in the spec. This process, which allows an LS to keep multiple routes to the same prefix, for example, is not compatible with the decision process of TRIP. Its complementary, to be certain, but thats not the same. If you took a normal TRIP LS and put it in front of a TRIP-GW gateway, it would probably not do the right thing. It would function, I think, but you would not be able to implement the appropriate policies to process the information being generated by the gateways. Do people concur with this view? If so, I would propose that we rename the protocol to the Gateway Registration Protocol (GREP). I think the acronym is neat; the protocol is used to search for a gateway, sort of, so grep (in the unix sense) kind of works. The protocol syntax and semantics remain unchanged. We will simply indicate that large pieces of TRIP are used wholesale by this protocol, referring the user to the appropriate sections of the TRIP spec. Thoughts? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Sep 6 21:01:45 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25842 for ; Fri, 6 Sep 2002 21:01:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g870vP220601; Fri, 6 Sep 2002 20:57:25 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g870tB220586 for ; Fri, 6 Sep 2002 20:55:11 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g870tBhN012241 for ; Fri, 6 Sep 2002 20:55:11 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 36BE54439E; Fri, 6 Sep 2002 20:55:06 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 0B1EE4439D for ; Fri, 6 Sep 2002 20:55:06 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g870t3o87279 for ; Fri, 6 Sep 2002 20:55:04 -0400 (EDT) Received: from ahmler4.mail.eds.com ([192.85.154.77]) by dusty; Fri Sep 6 20:55:03 EDT 2002 Received: from ahmlir1.mail.eds.com (ahmlir1-2.mail.eds.com [192.85.154.131]) by ahmler4.mail.eds.com (8.11.6/8.11.6) with ESMTP id g870t2a26508 for ; Fri, 6 Sep 2002 20:55:02 -0400 Received: from ahmlir1.mail.eds.com (localhost [127.0.0.1]) by ahmlir1.mail.eds.com (8.11.6/8.11.6) with ESMTP id g870t0l17459 for ; Fri, 6 Sep 2002 20:55:01 -0400 (EDT) Received: from usahm001.examhub.exch.eds.com (usahm001.examhub.exch.eds.com [207.37.138.140]) by ahmlir1.mail.eds.com (8.11.6/8.11.6) with ESMTP id g870t0w17455 for ; Fri, 6 Sep 2002 20:55:00 -0400 (EDT) Received: by usahm001.examhub.exch.eds.com with Internet Mail Service (5.5.2655.51) id ; Fri, 6 Sep 2002 20:54:58 -0400 Message-ID: <2BE915A69EF4D2119A0800805FF5E050116B76D0@BRSPM201> From: "Crizza, Roberto" To: list iptel Subject: RE: [IPTEL] New name for TRIP-GW MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.51) Content-Type: text/plain Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 6 Sep 2002 20:53:59 -0400 I agree with Radhika and in my opinion the pronunciation of TGRP is better than GREP. Regards Roberto Crizza EDS Brazil -----Original Message----- From: Roy, Radhika R, ALASO [mailto:rrroy@att.com] Sent: Friday, September 06, 2002 17:09 To: Jonathan Rosenberg; list iptel Subject: RE: [IPTEL] New name for TRIP-GW I believe that the Gateway Registration Protocol (GREP) is too broad a term. In fact, this registration protocol is only applicable for the PSTN-IP Telephony GWs for registration of the routable telephone numbers. So, I propose the name as follows: "Telephony Gateway Registration Protocol (TGRP)" Thanks, Radhika R. Roy AT&T -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Friday, September 06, 2002 3:42 PM To: list iptel Subject: [IPTEL] New name for TRIP-GW Folks, I'd like to propose a name change for the TRIP-GW (aka TRIP-LITE) protocol. The reason is, as written, TRIP-GW is not actually an extension to TRIP. Nor is it a subset of TRIP. It differs in the consolidation process defined in the spec. This process, which allows an LS to keep multiple routes to the same prefix, for example, is not compatible with the decision process of TRIP. Its complementary, to be certain, but thats not the same. If you took a normal TRIP LS and put it in front of a TRIP-GW gateway, it would probably not do the right thing. It would function, I think, but you would not be able to implement the appropriate policies to process the information being generated by the gateways. Do people concur with this view? If so, I would propose that we rename the protocol to the Gateway Registration Protocol (GREP). I think the acronym is neat; the protocol is used to search for a gateway, sort of, so grep (in the unix sense) kind of works. The protocol syntax and semantics remain unchanged. We will simply indicate that large pieces of TRIP are used wholesale by this protocol, referring the user to the appropriate sections of the TRIP spec. Thoughts? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sat Sep 7 03:32:14 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09272 for ; Sat, 7 Sep 2002 03:32:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g877KS222494; Sat, 7 Sep 2002 03:20:28 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g877Ib222470 for ; Sat, 7 Sep 2002 03:18:37 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g877IbhN014791 for ; Sat, 7 Sep 2002 03:18:37 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id E363D4439E; Sat, 7 Sep 2002 03:18:31 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id BA7594439D for ; Sat, 7 Sep 2002 03:18:31 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g877ITk27730 for ; Sat, 7 Sep 2002 03:18:30 -0400 (EDT) Received: from powaismtp.lntinfotech.com ([203.199.54.37]) by dusty; Sat Sep 7 03:18:29 EDT 2002 Received: from Bangalore.lntinfotech.com ([107.108.204.3]) by powaismtp.lntinfotech.com (Lotus Domino Release 5.0.9) with ESMTP id 2002090712502950:56007 ; Sat, 7 Sep 2002 12:50:29 +0530 Subject: RE: [IPTEL] New name for TRIP-GW To: iptel@lists.bell-labs.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: Rakesh.Khemani@lntinfotech.com MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 09/07/2002 12:44:49 PM, Itemize by SMTP Server on POWAISMTP/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 09/07/2002 12:50:29 PM, Serialize by Router on POWAISMTP/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 09/07/2002 12:50:34 PM, Serialize complete at 09/07/2002 12:50:34 PM Content-type: text/plain; charset=us-ascii Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sat, 7 Sep 2002 12:44:46 +0530 I too agree with Radhika and Roberto. I believe the iptel workgroup should not do away with "T" (read telephony) in the protocol naming convention. Telephony is the essence of iptel and its work. TGRP conveys the functional meaning succinctly. Regards, Rakesh Khemani. L & T Infotech Ltd. Bangalore, India. "Crizza, Roberto" om> cc: Sent by: Subject: RE: [IPTEL] New name for TRIP-GW iptel-admin@lists.bel l-labs.com 07/09/2002 06:23 AM I agree with Radhika and in my opinion the pronunciation of TGRP is better than GREP. Regards Roberto Crizza EDS Brazil -----Original Message----- From: Roy, Radhika R, ALASO [mailto:rrroy@att.com] Sent: Friday, September 06, 2002 17:09 To: Jonathan Rosenberg; list iptel Subject: RE: [IPTEL] New name for TRIP-GW I believe that the Gateway Registration Protocol (GREP) is too broad a term. In fact, this registration protocol is only applicable for the PSTN-IP Telephony GWs for registration of the routable telephone numbers. So, I propose the name as follows: "Telephony Gateway Registration Protocol (TGRP)" Thanks, Radhika R. Roy AT&T -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Friday, September 06, 2002 3:42 PM To: list iptel Subject: [IPTEL] New name for TRIP-GW Folks, I'd like to propose a name change for the TRIP-GW (aka TRIP-LITE) protocol. The reason is, as written, TRIP-GW is not actually an extension to TRIP. Nor is it a subset of TRIP. It differs in the consolidation process defined in the spec. This process, which allows an LS to keep multiple routes to the same prefix, for example, is not compatible with the decision process of TRIP. Its complementary, to be certain, but thats not the same. If you took a normal TRIP LS and put it in front of a TRIP-GW gateway, it would probably not do the right thing. It would function, I think, but you would not be able to implement the appropriate policies to process the information being generated by the gateways. Do people concur with this view? If so, I would propose that we rename the protocol to the Gateway Registration Protocol (GREP). I think the acronym is neat; the protocol is used to search for a gateway, sort of, so grep (in the unix sense) kind of works. The protocol syntax and semantics remain unchanged. We will simply indicate that large pieces of TRIP are used wholesale by this protocol, referring the user to the appropriate sections of the TRIP spec. Thoughts? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sat Sep 7 04:20:43 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09709 for ; Sat, 7 Sep 2002 04:20:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g878GN223321; Sat, 7 Sep 2002 04:16:23 -0400 Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g878EN223296 for ; Sat, 7 Sep 2002 04:14:23 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by crufty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g878EMLI005400 for ; Sat, 7 Sep 2002 04:14:22 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 9902C4439E; Sat, 7 Sep 2002 04:14:17 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 701944439D for ; Sat, 7 Sep 2002 04:14:17 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g878EGo05520 for ; Sat, 7 Sep 2002 04:14:16 -0400 (EDT) Received: from india-msg-core-1.cisco.com ([64.104.129.221]) by dusty; Sat Sep 7 04:14:15 EDT 2002 Received: from cbin3-mira-01.cisco.com (localhost [127.0.0.1]) by india-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g87Dh4oX019687; Sat, 7 Sep 2002 13:43:05 GMT Received: from cisco.com ([64.104.136.176]) by cbin3-mira-01.cisco.com (Mirapoint) with ESMTP id ACL70876; Sat, 7 Sep 2002 13:39:11 +0530 (IST) Message-ID: <3D79B59F.90608@cisco.com> From: "Jayasimha M.R" Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: "Roy, Radhika R, ALASO" Cc: Jonathan Rosenberg , list iptel Subject: Re: [IPTEL] New name for TRIP-GW References: <62DA45D4963FA747BA1B253E266760F903BAA374@OCCLUST04EVS1.ugd.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sat, 07 Sep 2002 13:45:27 +0530 Content-Transfer-Encoding: 7bit I would support TGRP with T being "Trunking" Instead of "Telephony" Thanks, Jayasimha Roy, Radhika R, ALASO wrote: > I believe that the Gateway Registration Protocol (GREP) is too broad a > term. In fact, this registration protocol is only applicable for the > PSTN-IP Telephony GWs for registration of the routable telephone > numbers. > > So, I propose the name as follows: > > "Telephony Gateway Registration Protocol (TGRP)" > > Thanks, > > Radhika R. Roy > AT&T > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, September 06, 2002 3:42 PM > To: list iptel > Subject: [IPTEL] New name for TRIP-GW > > > Folks, > > I'd like to propose a name change for the TRIP-GW (aka TRIP-LITE) > protocol. > > The reason is, as written, TRIP-GW is not actually an extension to TRIP. > > Nor is it a subset of TRIP. It differs in the consolidation process > defined in the spec. This process, which allows an LS to keep multiple > routes to the same prefix, for example, is not compatible with the > decision process of TRIP. Its complementary, to be certain, but thats > not the same. If you took a normal TRIP LS and put it in front of a > TRIP-GW gateway, it would probably not do the right thing. It would > function, I think, but you would not be able to implement the > appropriate policies to process the information being generated by the > gateways. > > Do people concur with this view? > > If so, I would propose that we rename the protocol to the Gateway > Registration Protocol (GREP). I think the acronym is neat; the protocol > is used to search for a gateway, sort of, so grep (in the unix sense) > kind of works. > > The protocol syntax and semantics remain unchanged. We will simply > indicate that large pieces of TRIP are used wholesale by this protocol, > referring the user to the appropriate sections of the TRIP spec. > > Thoughts? > > Thanks, > Jonathan R. > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sat Sep 7 14:37:22 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16895 for ; Sat, 7 Sep 2002 14:37:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g87IXN226222; Sat, 7 Sep 2002 14:33:23 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g87IV9226207 for ; Sat, 7 Sep 2002 14:31:09 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g87IV9hN020170 for ; Sat, 7 Sep 2002 14:31:09 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 5A8554439E; Sat, 7 Sep 2002 14:31:04 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 26C254439D for ; Sat, 7 Sep 2002 14:31:04 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g87IV2o31460 for ; Sat, 7 Sep 2002 14:31:02 -0400 (EDT) Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by dusty; Sat Sep 7 14:31:01 EDT 2002 Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g87IV0KB014954; Sat, 7 Sep 2002 11:31:00 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g87IUx4t002989; Sat, 7 Sep 2002 11:30:59 -0700 (PDT) Received: from DHAVAL-W2K2.cisco.com (sjc-vpn3-608.cisco.com [10.21.66.96]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA18893; Sat, 7 Sep 2002 11:30:57 -0700 (PDT) Message-Id: <4.3.2.7.2.20020907105202.041a7c70@mira-sjc5-5.cisco.com> X-Sender: dhaval@mira-sjc5-5.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Rakesh.Khemani@lntinfotech.com From: Dhaval Shah Subject: RE: [IPTEL] New name for TRIP-GW Cc: iptel@lists.bell-labs.com In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_55217017==_.ALT" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sat, 07 Sep 2002 11:14:07 -0700 --=====================_55217017==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Folx, Based on: 1. Jonathan's initial analogy with grep, which is cool 2. The suggestion for something denoting telephony in the name 3. Sounding, my 2 cents on this is TGREP (Telephony Gateway Registration Protocol). Thx, Dhaval At 12:44 PM 9/7/2002 +0530, Rakesh.Khemani@lntinfotech.com wrote: >I too agree with Radhika and Roberto. I believe the iptel workgroup should >not do away with "T" (read telephony) in the protocol naming convention. >Telephony is the essence of iptel and its work. TGRP conveys the functional >meaning succinctly. > > >Regards, >Rakesh Khemani. >L & T Infotech Ltd. >Bangalore, India. > > > > > > > > "Crizza, > Roberto" > > om> cc: > > Sent by: Subject: RE: [IPTEL] > New name for TRIP-GW > iptel-admin@lists.bel > > l-labs.com > > > > > > 07/09/2002 06:23 > AM > > > > > > > > >I agree with Radhika and in my opinion the pronunciation of TGRP is better >than GREP. > >Regards > >Roberto Crizza >EDS Brazil > >-----Original Message----- >From: Roy, Radhika R, ALASO [mailto:rrroy@att.com] >Sent: Friday, September 06, 2002 17:09 >To: Jonathan Rosenberg; list iptel >Subject: RE: [IPTEL] New name for TRIP-GW > > >I believe that the Gateway Registration Protocol (GREP) is too broad a >term. In fact, this registration protocol is only applicable for the >PSTN-IP Telephony GWs for registration of the routable telephone >numbers. > >So, I propose the name as follows: > >"Telephony Gateway Registration Protocol (TGRP)" > >Thanks, > >Radhika R. Roy >AT&T > >-----Original Message----- >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >Sent: Friday, September 06, 2002 3:42 PM >To: list iptel >Subject: [IPTEL] New name for TRIP-GW > > >Folks, > >I'd like to propose a name change for the TRIP-GW (aka TRIP-LITE) >protocol. > >The reason is, as written, TRIP-GW is not actually an extension to TRIP. > >Nor is it a subset of TRIP. It differs in the consolidation process >defined in the spec. This process, which allows an LS to keep multiple >routes to the same prefix, for example, is not compatible with the >decision process of TRIP. Its complementary, to be certain, but thats >not the same. If you took a normal TRIP LS and put it in front of a >TRIP-GW gateway, it would probably not do the right thing. It would >function, I think, but you would not be able to implement the >appropriate policies to process the information being generated by the >gateways. > >Do people concur with this view? > >If so, I would propose that we rename the protocol to the Gateway >Registration Protocol (GREP). I think the acronym is neat; the protocol >is used to search for a gateway, sort of, so grep (in the unix sense) >kind of works. > >The protocol syntax and semantics remain unchanged. We will simply >indicate that large pieces of TRIP are used wholesale by this protocol, >referring the user to the appropriate sections of the TRIP spec. > >Thoughts? > >Thanks, >Jonathan R. >-- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com > >_______________________________________________ >IPTEL mailing list >IPTEL@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/iptel >_______________________________________________ >IPTEL mailing list >IPTEL@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/iptel >_______________________________________________ >IPTEL mailing list >IPTEL@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/iptel > > > > >_______________________________________________ >IPTEL mailing list >IPTEL@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/iptel --=====================_55217017==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Folx,

Based on:

1. Jonathan's  initial analogy with grep, which is cool
2. The suggestion for something denoting telephony in the name
3. Sounding,

my 2 cents on this is TGREP (Telephony Gateway Registration Protocol).

Thx,
Dhaval

At 12:44 PM 9/7/2002 +0530, Rakesh.Khemani@lntinfotech.com wrote:

I too agree with Radhika and Roberto. I believe  the iptel workgroup should
not do away with "T" (read telephony) in the protocol  naming convention.
Telephony is the essence of iptel and its work. TGRP conveys the functional
meaning succinctly.


Regards,
Rakesh Khemani.
L & T Infotech Ltd.
Bangalore, India.





            &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =             &nbs= p;         
            &nbs= p;       "Crizza, Roberto"          &nb= sp;            &= nbsp;            = ;            &nb= sp;            
            &nbs= p;       <roberto.crizza@eds.c       To:     list iptel <iptel@lists.bell-labs.com>    
            &nbs= p;       om>           &nbs= p;             cc:            &= nbsp;            = ;            &nb= sp;         
            &nbs= p;       Sent by:            &= nbsp;       Subject:     RE: [IPTEL] New name for TRIP-GW     
            &nbs= p;       iptel-admin@lists.bel         &= nbsp;            = ;            &nb= sp;            &= nbsp;         
            &nbs= p;       l-labs.com           =             &nbs= p;            &n= bsp;            =             &nbs= p;      
            &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =             &nbs= p;         
            &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =             &nbs= p;         
            &nbs= p;       07/09/2002 06:23 AM            &n= bsp;            =             &nbs= p;            &n= bsp;        
            &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =             &nbs= p;         
            &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =             &nbs= p;         




I agree with Radhika and in my opinion the pronunciation of TGRP is better
than GREP.

Regards

Roberto Crizza
EDS Brazil

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
Sent: Friday, September 06, 2002 17:09
To: Jonathan Rosenberg; list iptel
Subject: RE: [IPTEL] New name for TRIP-GW


I believe that the Gateway Registration Protocol (GREP) is too broad a
term. In fact, this registration protocol is only applicable for=20 the
PSTN-IP Telephony GWs for registration of the routable telephone
numbers.

So, I propose the name as follows:

"Telephony Gateway Registration Protocol (TGRP)"

Thanks,

Radhika R. Roy
AT&T

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Friday, September 06, 2002 3:42 PM
To: list iptel
Subject: [IPTEL] New name for TRIP-GW


Folks,

I'd like to propose a name change for the TRIP-GW (aka TRIP-LITE)
protocol.

The reason is, as written, TRIP-GW is not actually an extension to TRIP.

Nor is it a subset of TRIP. It differs in the consolidation process
defined in the spec. This process, which allows an LS to keep multiple
routes to the same prefix, for example, is not compatible with the
decision process of TRIP. Its complementary, to be certain, but thats
not the same. If you took a normal TRIP LS and put it in front of a
TRIP-GW gateway, it would probably not do the right thing. It would
function, I think, but you would not be able to implement the
appropriate policies to process the information being generated by the
gateways.

Do people concur with this view?

If so, I would propose that we rename the protocol to the Gateway
Registration Protocol (GREP). I think the acronym is neat; the protocol
is used to search for a gateway, sort of, so grep (in the unix sense)
kind of works.

The protocol syntax and semantics remain unchanged. We will simply
indicate that large pieces of TRIP are used wholesale by this protocol,
referring the user to the appropriate sections of the TRIP spec.

Thoughts?

Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.            = ;    72 Eagle Rock Ave.
Chief Scientist           &= nbsp;            = ;     First Floor
dynamicsoft           = ;            &nb= sp;         East Hanover, NJ 07936
jdrosen@dynamicsoft.com         = ;            FAX:   (973) 952-5050
http://www.jdrosen.net  = ;            &nb= sp;      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel



_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel
--=====================_55217017==_.ALT-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sat Sep 7 16:46:21 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18262 for ; Sat, 7 Sep 2002 16:46:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g87Kep227067; Sat, 7 Sep 2002 16:40:51 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g87Kdp227045 for ; Sat, 7 Sep 2002 16:39:51 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g87KdphN020919 for ; Sat, 7 Sep 2002 16:39:51 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 105354439E; Sat, 7 Sep 2002 16:39:46 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id DB8DE4439D for ; Sat, 7 Sep 2002 16:39:45 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g87Kdik59341 for ; Sat, 7 Sep 2002 16:39:44 -0400 (EDT) Received: from imo-d02.mx.aol.com ([205.188.157.34]) by dusty; Sat Sep 7 16:39:44 EDT 2002 Received: from JustMeUnOr@aol.com by imo-d02.mx.aol.com (mail_out_v34.10.) id c.50.112d7aaa (30950); Sat, 7 Sep 2002 16:39:22 -0400 (EDT) From: JustMeUnOr@aol.com Message-ID: <50.112d7aaa.2aabbdf9@aol.com> Subject: Re: [IPTEL] New name for TRIP-GW To: dhaval@cisco.com, Rakesh.Khemani@lntinfotech.com Cc: iptel@lists.bell-labs.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_50.112d7aaa.2aabbdf9_boundary" X-Mailer: AOL 7.0 for Windows US sub 10513 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sat, 7 Sep 2002 16:39:21 EDT --part1_50.112d7aaa.2aabbdf9_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit TGREP Sounds good to me too... Like was previously stated, I think the T should represent trunking, as theres no current Dirrect TRIP applications for PBX'ish (Gateing/Queing) , or "line side" issues --part1_50.112d7aaa.2aabbdf9_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit TGREP Sounds good to me too...    Like was previously stated, I think the T should represent trunking, as theres no current Dirrect TRIP applications for PBX'ish (Gateing/Queing) , or "line side" issues --part1_50.112d7aaa.2aabbdf9_boundary-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Sep 13 03:40:55 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27640 for ; Fri, 13 Sep 2002 03:40:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8D6xn202228; Fri, 13 Sep 2002 02:59:49 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8D6wH202215 for ; Fri, 13 Sep 2002 02:58:17 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g8D6wHhN073393 for ; Fri, 13 Sep 2002 02:58:17 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 58C644439E; Fri, 13 Sep 2002 02:58:12 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 327CB4439D for ; Fri, 13 Sep 2002 02:58:12 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g8D6wAo78119 for ; Fri, 13 Sep 2002 02:58:10 -0400 (EDT) Received: from india-msg-core-1.cisco.com ([64.104.129.221]) by dusty; Fri Sep 13 02:58:09 EDT 2002 Received: from cbin3-mira-01.cisco.com (localhost [127.0.0.1]) by india-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8DCR1pU028471; Fri, 13 Sep 2002 12:27:01 GMT Received: from cisco.com ([64.104.136.176]) by cbin3-mira-01.cisco.com (Mirapoint) with ESMTP id ACM50429; Fri, 13 Sep 2002 12:23:12 +0530 (IST) Message-ID: <3D818CC1.5060608@cisco.com> From: "Jayasimha M.R" Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Jonathan Rosenberg Cc: list iptel Subject: Re: [IPTEL] New name for TRIP-GW References: <3D7904F9.4020800@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 13 Sep 2002 12:29:13 +0530 Content-Transfer-Encoding: 7bit Hi Jonathan, I agree with Dhaval, TGREP sounds good. As i said earlier, I propose to call this as: "Trunking Gateway REgistration Protocol" instead of "Telephony Gateway REgistration Protocol". Thanks, Jayasimha Jonathan Rosenberg wrote: > Folks, > > I'd like to propose a name change for the TRIP-GW (aka TRIP-LITE) protocol. > > The reason is, as written, TRIP-GW is not actually an extension to TRIP. > Nor is it a subset of TRIP. It differs in the consolidation process > defined in the spec. This process, which allows an LS to keep multiple > routes to the same prefix, for example, is not compatible with the > decision process of TRIP. Its complementary, to be certain, but thats > not the same. If you took a normal TRIP LS and put it in front of a > TRIP-GW gateway, it would probably not do the right thing. It would > function, I think, but you would not be able to implement the > appropriate policies to process the information being generated by the > gateways. > > Do people concur with this view? > > If so, I would propose that we rename the protocol to the Gateway > Registration Protocol (GREP). I think the acronym is neat; the protocol > is used to search for a gateway, sort of, so grep (in the unix sense) > kind of works. > > The protocol syntax and semantics remain unchanged. We will simply > indicate that large pieces of TRIP are used wholesale by this protocol, > referring the user to the appropriate sections of the TRIP spec. > > Thoughts? > > Thanks, > Jonathan R. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Sep 16 03:12:52 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27562 for ; Mon, 16 Sep 2002 03:12:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8G7Dl225951; Mon, 16 Sep 2002 03:13:47 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8G75w225912 for ; Mon, 16 Sep 2002 03:05:58 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g8G75whN099295 for ; Mon, 16 Sep 2002 03:05:58 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id E8FC14439E; Mon, 16 Sep 2002 03:05:53 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id A87254439D for ; Mon, 16 Sep 2002 03:05:52 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g8G75pk17608 for ; Mon, 16 Sep 2002 03:05:51 -0400 (EDT) Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by dusty; Mon Sep 16 03:05:50 EDT 2002 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8G75j3x028498 for ; Mon, 16 Sep 2002 00:05:45 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8G75nki006837; Mon, 16 Sep 2002 00:05:49 -0700 (PDT) Received: from DHAVAL-W2K2.cisco.com (syd-vpn-client-254-5.cisco.com [10.66.254.5]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id AAA10483; Mon, 16 Sep 2002 00:05:45 -0700 (PDT) Message-Id: <4.3.2.7.2.20020915205601.03b234f0@mira-sjc5-5.cisco.com> X-Sender: dhaval@mira-sjc5-5.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: iptel@lists.bell-labs.com From: Dhaval Shah Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_35214135==_.ALT" Subject: [IPTEL] Trip-gw draft status Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Mon, 16 Sep 2002 00:05:44 -0700 --=====================_35214135==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Folx, Thx for all of your comments regarding draft-iptel-trip-gw-00.txt In preparation for the upcoming IETF, we are in process of updating the draft based on various comments. This would also include the following significant updates: - multiple address family handling and carrier attribute implications - carrier syntax related stuff including international carriers - elaborating on kinds of things that can be done in consolidation section Please expect the updated version sometime this week and let us have your feedback. Thx, Dhaval (for the trip-gw team) --=====================_35214135==_.ALT Content-Type: text/html; charset="us-ascii" Hi Folx,

Thx for all of your comments regarding draft-iptel-trip-gw-00.txt

In preparation for the upcoming IETF, we are in process of updating the draft based on various comments.
This would also include the following significant  updates:
- multiple address family handling and carrier attribute implications
- carrier syntax related stuff including international carriers
- elaborating on kinds of things that can be done in consolidation section

Please expect the updated version sometime this week and let us have your feedback.

Thx,
Dhaval (for the trip-gw team)







 --=====================_35214135==_.ALT-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Sep 17 02:35:34 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05772 for ; Tue, 17 Sep 2002 02:35:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8H6Ub232599; Tue, 17 Sep 2002 02:30:37 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8H6P9232568 for ; Tue, 17 Sep 2002 02:25:09 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g8H6P8hN009032 for ; Tue, 17 Sep 2002 02:25:09 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id A7DA7443A5; Tue, 17 Sep 2002 02:25:03 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 7EFAC443A4 for ; Tue, 17 Sep 2002 02:25:03 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g8H6P2k18042 for ; Tue, 17 Sep 2002 02:25:02 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by dusty; Tue Sep 17 02:25:02 EDT 2002 Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g8H6OvYH024649; Tue, 17 Sep 2002 02:24:58 -0400 (EDT) Message-ID: <3D86CAB8.7050305@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jayasimha M.R" Cc: list iptel Subject: Re: [IPTEL] New name for TRIP-GW References: <3D7904F9.4020800@dynamicsoft.com> <3D818CC1.5060608@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Tue, 17 Sep 2002 02:24:56 -0400 Content-Transfer-Encoding: 7bit OK, lets go with "Telephony Gateway Registration Protocol". Trunking is too specific. The most important thing here, of course, is the statement that this is not TRIP; that it uses a different back end processing (not the decision process outlined in RFC 3219), but rather this consolidation process. -Jonathan R. Jayasimha M.R wrote: > Hi Jonathan, > > I agree with Dhaval, TGREP sounds good. As i said earlier, > I propose to call this as: > > "Trunking Gateway REgistration Protocol" instead of > "Telephony Gateway REgistration Protocol". > > > Thanks, > Jayasimha > > Jonathan Rosenberg wrote: > >> Folks, >> >> I'd like to propose a name change for the TRIP-GW (aka TRIP-LITE) >> protocol. >> >> The reason is, as written, TRIP-GW is not actually an extension to >> TRIP. Nor is it a subset of TRIP. It differs in the consolidation >> process defined in the spec. This process, which allows an LS to keep >> multiple routes to the same prefix, for example, is not compatible >> with the decision process of TRIP. Its complementary, to be certain, >> but thats not the same. If you took a normal TRIP LS and put it in >> front of a TRIP-GW gateway, it would probably not do the right thing. >> It would function, I think, but you would not be able to implement the >> appropriate policies to process the information being generated by the >> gateways. >> >> Do people concur with this view? >> >> If so, I would propose that we rename the protocol to the Gateway >> Registration Protocol (GREP). I think the acronym is neat; the >> protocol is used to search for a gateway, sort of, so grep (in the >> unix sense) kind of works. >> >> The protocol syntax and semantics remain unchanged. We will simply >> indicate that large pieces of TRIP are used wholesale by this >> protocol, referring the user to the appropriate sections of the TRIP >> spec. >> >> Thoughts? >> >> Thanks, >> Jonathan R. > > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sun Sep 22 16:08:46 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12634 for ; Sun, 22 Sep 2002 16:08:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8MJu2207869; Sun, 22 Sep 2002 15:56:02 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8MJl2207824 for ; Sun, 22 Sep 2002 15:47:02 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g8MJl1hN066652 for ; Sun, 22 Sep 2002 15:47:01 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 7DB97443A5; Sun, 22 Sep 2002 15:46:56 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 4FCDE443A4 for ; Sun, 22 Sep 2002 15:46:56 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g8MJktk05929 for ; Sun, 22 Sep 2002 15:46:55 -0400 (EDT) Received: from sj-msg-core-4.cisco.com ([171.71.163.54]) by dusty; Sun Sep 22 15:46:54 EDT 2002 Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g8MJkgW4014439; Sun, 22 Sep 2002 12:46:43 -0700 (PDT) Received: from RAJNEESH-W2K2.cisco.com (sjc-vpn1-958.cisco.com [10.21.99.190]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AFF13125; Sun, 22 Sep 2002 12:42:44 -0700 (PDT) Message-Id: <4.3.2.7.2.20020922124507.04e8b288@mira-sjc5-4.cisco.com> X-Sender: rajneesh@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jonathan Rosenberg , "Jayasimha M.R" From: Rajneesh Kumar Subject: Re: [IPTEL] New name for TRIP-GW Cc: list iptel In-Reply-To: <3D86CAB8.7050305@dynamicsoft.com> References: <3D7904F9.4020800@dynamicsoft.com> <3D818CC1.5060608@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sun, 22 Sep 2002 12:46:41 -0700 Should we take this as the consensus then ? I would like to incorporate this name change ASAP in the latest draft which is progress as I write. Thanks, Rajneesh ( for the draft's authors ) At 11:24 PM 9/16/2002, Jonathan Rosenberg wrote: >OK, lets go with "Telephony Gateway Registration Protocol". Trunking is >too specific. > >The most important thing here, of course, is the statement that this is >not TRIP; that it uses a different back end processing (not the decision >process outlined in RFC 3219), but rather this consolidation process. > >-Jonathan R. > >Jayasimha M.R wrote: >>Hi Jonathan, >>I agree with Dhaval, TGREP sounds good. As i said earlier, >>I propose to call this as: >>"Trunking Gateway REgistration Protocol" instead of >>"Telephony Gateway REgistration Protocol". >> >>Thanks, >>Jayasimha >>Jonathan Rosenberg wrote: >> >>>Folks, >>> >>>I'd like to propose a name change for the TRIP-GW (aka TRIP-LITE) protocol. >>> >>>The reason is, as written, TRIP-GW is not actually an extension to TRIP. >>>Nor is it a subset of TRIP. It differs in the consolidation process >>>defined in the spec. This process, which allows an LS to keep multiple >>>routes to the same prefix, for example, is not compatible with the >>>decision process of TRIP. Its complementary, to be certain, but thats >>>not the same. If you took a normal TRIP LS and put it in front of a >>>TRIP-GW gateway, it would probably not do the right thing. It would >>>function, I think, but you would not be able to implement the >>>appropriate policies to process the information being generated by the >>>gateways. >>> >>>Do people concur with this view? >>> >>>If so, I would propose that we rename the protocol to the Gateway >>>Registration Protocol (GREP). I think the acronym is neat; the protocol >>>is used to search for a gateway, sort of, so grep (in the unix sense) >>>kind of works. >>> >>>The protocol syntax and semantics remain unchanged. We will simply >>>indicate that large pieces of TRIP are used wholesale by this protocol, >>>referring the user to the appropriate sections of the TRIP spec. >>> >>>Thoughts? >>> >>>Thanks, >>>Jonathan R. >> > >-- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com > >_______________________________________________ >IPTEL mailing list >IPTEL@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sun Sep 22 21:10:30 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15948 for ; Sun, 22 Sep 2002 21:10:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8N1C7209417; Sun, 22 Sep 2002 21:12:07 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8N17V209386 for ; Sun, 22 Sep 2002 21:07:31 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by crufty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g8N17VLI057334 for ; Sun, 22 Sep 2002 21:07:31 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 4B35B443A5; Sun, 22 Sep 2002 21:07:26 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 1FD6D443A4 for ; Sun, 22 Sep 2002 21:07:26 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g8N17Oo97177 for ; Sun, 22 Sep 2002 21:07:24 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by dusty; Sun Sep 22 21:07:24 EDT 2002 Received: from dynamicsoft.com ([63.113.46.50]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g8N17MYH027634; Sun, 22 Sep 2002 21:07:23 -0400 (EDT) Message-ID: <3D8E6949.8020104@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rajneesh Kumar Cc: "Jayasimha M.R" , list iptel Subject: Re: [IPTEL] New name for TRIP-GW References: <3D7904F9.4020800@dynamicsoft.com> <3D818CC1.5060608@cisco.com> <4.3.2.7.2.20020922124507.04e8b288@mira-sjc5-4.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sun, 22 Sep 2002 21:07:21 -0400 Content-Transfer-Encoding: 7bit Yes. Please include this change in the next rev. -Jonathan R. Rajneesh Kumar wrote: > Should we take this as the consensus then ? I would like to incorporate > this name change ASAP in the latest draft which is progress as I write. > > Thanks, > Rajneesh ( for the draft's authors ) > > At 11:24 PM 9/16/2002, Jonathan Rosenberg wrote: > >> OK, lets go with "Telephony Gateway Registration Protocol". Trunking >> is too specific. >> >> The most important thing here, of course, is the statement that this >> is not TRIP; that it uses a different back end processing (not the >> decision process outlined in RFC 3219), but rather this consolidation >> process. >> >> -Jonathan R. >> >> Jayasimha M.R wrote: >> >>> Hi Jonathan, >>> I agree with Dhaval, TGREP sounds good. As i said earlier, >>> I propose to call this as: >>> "Trunking Gateway REgistration Protocol" instead of >>> "Telephony Gateway REgistration Protocol". >>> >>> Thanks, >>> Jayasimha >>> Jonathan Rosenberg wrote: >>> >>>> Folks, >>>> >>>> I'd like to propose a name change for the TRIP-GW (aka TRIP-LITE) >>>> protocol. >>>> >>>> The reason is, as written, TRIP-GW is not actually an extension to >>>> TRIP. Nor is it a subset of TRIP. It differs in the consolidation >>>> process defined in the spec. This process, which allows an LS to >>>> keep multiple routes to the same prefix, for example, is not >>>> compatible with the decision process of TRIP. Its complementary, to >>>> be certain, but thats not the same. If you took a normal TRIP LS and >>>> put it in front of a TRIP-GW gateway, it would probably not do the >>>> right thing. It would function, I think, but you would not be able >>>> to implement the appropriate policies to process the information >>>> being generated by the gateways. >>>> >>>> Do people concur with this view? >>>> >>>> If so, I would propose that we rename the protocol to the Gateway >>>> Registration Protocol (GREP). I think the acronym is neat; the >>>> protocol is used to search for a gateway, sort of, so grep (in the >>>> unix sense) kind of works. >>>> >>>> The protocol syntax and semantics remain unchanged. We will simply >>>> indicate that large pieces of TRIP are used wholesale by this >>>> protocol, referring the user to the appropriate sections of the TRIP >>>> spec. >>>> >>>> Thoughts? >>>> >>>> Thanks, >>>> Jonathan R. >>> >>> >> >> -- >> Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >> Chief Scientist First Floor >> dynamicsoft East Hanover, NJ 07936 >> jdrosen@dynamicsoft.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.dynamicsoft.com >> >> _______________________________________________ >> IPTEL mailing list >> IPTEL@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/iptel > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sun Sep 22 23:22:46 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18304 for ; Sun, 22 Sep 2002 23:22:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8N3Il210171; Sun, 22 Sep 2002 23:18:47 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8N3HQ210157 for ; Sun, 22 Sep 2002 23:17:26 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by crufty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g8N3HQLI058042 for ; Sun, 22 Sep 2002 23:17:26 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id E6BBF443A5; Sun, 22 Sep 2002 23:17:21 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id BD1DB443A4 for ; Sun, 22 Sep 2002 23:17:20 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g8N3HJk25270 for ; Sun, 22 Sep 2002 23:17:19 -0400 (EDT) Received: from DRYPTOSAURUS.ACCESS.NET.ID ([202.180.0.11]) by dusty; Sun Sep 22 23:17:18 EDT 2002 Received: from TAPLaptop.access.net.id (unknown [202.180.5.169]) by DRYPTOSAURUS.ACCESS.NET.ID (Postfix) with ESMTP id E494F77A6; Mon, 23 Sep 2002 10:09:03 +0700 (WIT) Message-Id: <5.1.0.14.0.20020923101307.018b4300@pop3.access.net.id> X-Sender: teddyap@pop3.access.net.id X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: Jonathan Rosenberg From: Teddy A PURWADI Subject: Re: [IPTEL] New name for TRIP-GW Cc: Rajneesh Kumar , "Jayasimha M.R" , list iptel In-Reply-To: <3D8E6949.8020104@dynamicsoft.com> References: <3D7904F9.4020800@dynamicsoft.com> <3D818CC1.5060608@cisco.com> <4.3.2.7.2.20020922124507.04e8b288@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Mon, 23 Sep 2002 10:17:11 +0700 At 21:07 22/09/2002 -0400, Jonathan Rosenberg wrote: Is TGRP terminology corellated to ENUM (IAB-ITU) on e164.arpa infrastructure? >Yes. Please include this change in the next rev. > >-Jonathan R. > >Rajneesh Kumar wrote: >>Should we take this as the consensus then ? I would like to incorporate >>this name change ASAP in the latest draft which is progress as I write. >>Thanks, >>Rajneesh ( for the draft's authors ) >>At 11:24 PM 9/16/2002, Jonathan Rosenberg wrote: >> >>>OK, lets go with "Telephony Gateway Registration Protocol". Trunking is >>>too specific. >>> >>>The most important thing here, of course, is the statement that this is >>>not TRIP; that it uses a different back end processing (not the decision >>>process outlined in RFC 3219), but rather this consolidation process. >>> >>>-Jonathan R. >>> >>>Jayasimha M.R wrote: >>> >>>>Hi Jonathan, >>>>I agree with Dhaval, TGREP sounds good. As i said earlier, >>>>I propose to call this as: >>>>"Trunking Gateway REgistration Protocol" instead of >>>>"Telephony Gateway REgistration Protocol". >>>> >>>>Thanks, >>>>Jayasimha >>>>Jonathan Rosenberg wrote: >>>> >>>>>Folks, >>>>> >>>>>I'd like to propose a name change for the TRIP-GW (aka TRIP-LITE) >>>>>protocol. >>>>> >>>>>The reason is, as written, TRIP-GW is not actually an extension to >>>>>TRIP. Nor is it a subset of TRIP. It differs in the consolidation >>>>>process defined in the spec. This process, which allows an LS to keep >>>>>multiple routes to the same prefix, for example, is not compatible >>>>>with the decision process of TRIP. Its complementary, to be certain, >>>>>but thats not the same. If you took a normal TRIP LS and put it in >>>>>front of a TRIP-GW gateway, it would probably not do the right thing. >>>>>It would function, I think, but you would not be able to implement the >>>>>appropriate policies to process the information being generated by the >>>>>gateways. >>>>> >>>>>Do people concur with this view? >>>>> >>>>>If so, I would propose that we rename the protocol to the Gateway >>>>>Registration Protocol (GREP). I think the acronym is neat; the >>>>>protocol is used to search for a gateway, sort of, so grep (in the >>>>>unix sense) kind of works. >>>>> >>>>>The protocol syntax and semantics remain unchanged. We will simply >>>>>indicate that large pieces of TRIP are used wholesale by this >>>>>protocol, referring the user to the appropriate sections of the TRIP spec. >>>>> >>>>>Thoughts? >>>>> >>>>>Thanks, >>>>>Jonathan R. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Sep 23 05:48:05 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03450 for ; Mon, 23 Sep 2002 05:48:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8N9kR212707; Mon, 23 Sep 2002 05:46:27 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8N9D7212160 for ; Mon, 23 Sep 2002 05:13:07 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g8N9D7hN071676 for ; Mon, 23 Sep 2002 05:13:07 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 6DEAB443A5; Mon, 23 Sep 2002 05:13:02 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 47BF3443A4 for ; Mon, 23 Sep 2002 05:13:02 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g8N9Cxo15490 for ; Mon, 23 Sep 2002 05:13:00 -0400 (EDT) Received: from relay2.clb.oleane.net ([213.56.31.22]) by dusty; Mon Sep 23 05:12:59 EDT 2002 Received: from chantal (upper-side.rain.fr [194.250.212.114]) by relay2.clb.oleane.net with SMTP id g8N9Cv3u031593 for ; Mon, 23 Sep 2002 11:12:58 +0200 Message-ID: <00a301c262e1$daa1ddc0$0701a8c0@upperside> From: "Peter Lewis" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009F_01C262F2.9DF0B200" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [IPTEL] International SIP Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Mon, 23 Sep 2002 11:16:09 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_009F_01C262F2.9DF0B200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The fourth edition of International SIP will take place January 14 to 17, 2003 in Paris. The most eminent specialists in this technology will be on hand to discuss technological and implementation issues. Indeed, a greater importance is given this year to PSTN and wireless operators deployment scenarios. All details at : http://www.upperside.fr/intersip03/sip03intro.htm ------=_NextPart_000_009F_01C262F2.9DF0B200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The fourth edition of International SIP will take = place=20 January 14 to 17, 2003 in Paris. The most eminent = specialists=20 in this technology will be on hand to discuss technological and = implementation=20 issues. Indeed, a greater importance is given this year to PSTN and = wireless=20 operators deployment scenarios.

All details at : http://www.upp= erside.fr/intersip03/sip03intro.htm

 

------=_NextPart_000_009F_01C262F2.9DF0B200-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Sep 23 10:09:26 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09731 for ; Mon, 23 Sep 2002 10:09:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8NE2O214554; Mon, 23 Sep 2002 10:02:24 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8NE0t214537 for ; Mon, 23 Sep 2002 10:00:55 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g8NE0shN074222 for ; Mon, 23 Sep 2002 10:00:54 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id B2AAD443A5; Mon, 23 Sep 2002 10:00:49 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 870B1443A4 for ; Mon, 23 Sep 2002 10:00:49 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g8NE0lo36178 for ; Mon, 23 Sep 2002 10:00:47 -0400 (EDT) Received: from plmler4.mail.eds.com ([199.228.142.74]) by dusty; Mon Sep 23 10:00:47 EDT 2002 Received: from plmlir4.mail.eds.com (plmlir4-2.mail.eds.com [199.228.142.134]) by plmler4.mail.eds.com (8.11.6/8.11.6) with ESMTP id g8NE0gL16212; Mon, 23 Sep 2002 09:00:43 -0500 Received: from plmlir4.mail.eds.com (localhost [127.0.0.1]) by plmlir4.mail.eds.com (8.11.6/8.11.6) with ESMTP id g8NE0fQ28288; Mon, 23 Sep 2002 09:00:41 -0500 (CDT) Received: from usplm002.exch.eds.com (USPLM002.txpln.us.eds.com [198.132.135.7]) by plmlir4.mail.eds.com (8.11.6/8.11.6) with ESMTP id g8NE0eW28280; Mon, 23 Sep 2002 09:00:41 -0500 (CDT) Received: by USPLM002.txpln.us.eds.com with Internet Mail Service (5.5.2655.51) id ; Mon, 23 Sep 2002 10:00:43 -0400 Message-ID: <2BE915A69EF4D2119A0800805FF5E05011A9DFA5@BRSPM201> From: "Crizza, Roberto" To: Peter Lewis Cc: iptel@lists.bell-labs.com Subject: RE: [IPTEL] International SIP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.51) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26309.6885533E" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Mon, 23 Sep 2002 09:59:17 -0400 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C26309.6885533E Content-Type: text/plain; charset="iso-8859-1" Peter Today all the companys has been reduced the costs, the company that I have been working is not different, I am working in this workgoroup by myself because I like know how is the technology is created. At EDS we have used conference call by Wordcom for discuss how we can sell the technology and what the client want to buy, the url is http://e-meetings.wcom.com/servlet/NFDMain the name is Net Conference. My question is, Could the International SIP can use this kind off technology for allow the people that won't travel to Paris can participate by conference ? Thanks in advance Roberto Crizza EDS Brasil -----Original Message----- From: Peter Lewis [mailto:peter.lewis@upperside.fr] Sent: Monday, September 23, 2002 06:16 To: iptel@lists.bell-labs.com Subject: [IPTEL] International SIP The fourth edition of International SIP will take place January 14 to 17, 2003 in Paris. The most eminent specialists in this technology will be on hand to discuss technological and implementation issues. Indeed, a greater importance is given this year to PSTN and wireless operators deployment scenarios. All details at : http://www.upperside.fr/intersip03/sip03intro.htm ------_=_NextPart_001_01C26309.6885533E Content-Type: text/html; charset="iso-8859-1"
Peter
 
Today all the companys has been reduced the costs, the company that I have been working is not different, I am working in this workgoroup by myself because I like know how is the technology is created.
 
At EDS we have used conference call by Wordcom for discuss how we can sell the technology and what the client want to buy, the url is http://e-meetings.wcom.com/servlet/NFDMain the name is Net Conference. My question is, Could the International SIP can use this kind off technology for allow the people that won't travel to Paris can participate by  conference ?
 
Thanks in advance
 
Roberto Crizza
EDS Brasil

 -----Original Message-----
From: Peter Lewis [mailto:peter.lewis@upperside.fr]
Sent: Monday, September 23, 2002 06:16
To: iptel@lists.bell-labs.com
Subject: [IPTEL] International SIP

The fourth edition of International SIP will take place January 14 to 17, 2003 in Paris. The most eminent specialists in this technology will be on hand to discuss technological and implementation issues. Indeed, a greater importance is given this year to PSTN and wireless operators deployment scenarios.

All details at : http://www.upperside.fr/intersip03/sip03intro.htm

 

------_=_NextPart_001_01C26309.6885533E-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Sep 23 20:42:00 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01007 for ; Mon, 23 Sep 2002 20:42:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8O0gj217694; Mon, 23 Sep 2002 20:42:45 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8O0b8217663 for ; Mon, 23 Sep 2002 20:37:08 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g8O0b7hN080370 for ; Mon, 23 Sep 2002 20:37:07 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 99C7C443A5; Mon, 23 Sep 2002 20:37:02 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 70DEF443A4 for ; Mon, 23 Sep 2002 20:37:02 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g8O0b0o94176 for ; Mon, 23 Sep 2002 20:37:00 -0400 (EDT) Received: from sj-msg-core-4.cisco.com ([171.71.163.54]) by dusty; Mon Sep 23 20:37:00 EDT 2002 Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g8O0axW4026414 for ; Mon, 23 Sep 2002 17:36:59 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8O0awK4002259 for ; Mon, 23 Sep 2002 17:36:58 -0700 (PDT) Received: from saratk-w2k.cisco.com (rtp-vpn1-591.cisco.com [10.82.226.79]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA29396 for ; Mon, 23 Sep 2002 17:36:52 -0700 (PDT) Message-Id: <4.3.2.7.2.20020923173028.00b6ec08@mira-sjc5-4.cisco.com> X-Sender: saratk@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: iptel@lists.bell-labs.com From: Sarath Babu Kamisetty Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [IPTEL] Why MUST LS be in same send receive mode with all peers ? Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Mon, 23 Sep 2002 17:36:50 -0700 Hi all, Section "4.2.1.1.2. Send Receive Capability" of RFC 3219 says - "An LS MUST be configured in the same Send Receive mode for all peers." Can someone please clarify why a LS MUST be in same send receive mode ? What could go wrong if we allow LS to be in different send receive modes with different peers ? Thanks, Sarath _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Sep 26 14:06:55 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16715 for ; Thu, 26 Sep 2002 14:06:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8QHxg202586; Thu, 26 Sep 2002 13:59:42 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8QHsM202558 for ; Thu, 26 Sep 2002 13:54:22 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g8QHsMhN010956 for ; Thu, 26 Sep 2002 13:54:22 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id E7B2F443A6; Thu, 26 Sep 2002 13:54:16 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id BC122443A4 for ; Thu, 26 Sep 2002 13:54:16 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g8QHsFI41302 for ; Thu, 26 Sep 2002 13:54:15 -0400 (EDT) Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by dusty; Thu Sep 26 13:54:14 EDT 2002 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8QHrj3x009282; Thu, 26 Sep 2002 10:53:45 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8QHrne5009292; Thu, 26 Sep 2002 10:53:50 -0700 (PDT) Received: from DHAVAL-W2K2.cisco.com (dhcp-128-107-209-98.cisco.com [128.107.209.98]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA08435; Thu, 26 Sep 2002 10:53:47 -0700 (PDT) Message-Id: <4.3.2.7.2.20020926104404.0410e940@mira-sjc5-5.cisco.com> X-Sender: dhaval@mira-sjc5-5.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jonathan Rosenberg , bpenfield@acmepacket.com, iptel@lists.bell-labs.com From: Dhaval Shah Subject: Re: [IPTEL] draft-ietf-iptel-trip-gw-00.txt has been posted In-Reply-To: <3D2FABE2.3010508@dynamicsoft.com> References: <3D07C83D.422AFEBB@cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_4405444==_.ALT" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 26 Sep 2002 10:53:25 -0700 --=====================_4405444==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Please see some comments and questions inlined. >I don't think we need to standardize a window, but the spec should suggest >that sufficiently large windows be used to provide a useful aggregated >statistic. We'll incorporate this. >Two comments. > >First, I agree with Bob that we should allow the carrier attribute to be >present in the trunk group address family. There was another comment to >the list regarding that. Will do that. Also, we are thinking of proposing to allow for T attribute to be present in C address family. >I think we can allow a mix, so long as the meaning of this is well >defined. One possible model is that there is no overlap. So, if a gateway >has 5 trunk groups, it can advertise three of them using trunk group >address family, and the other two using prefix address families. This >would allow for an LS to convert the three trunk group family routes to >prefix routes, and then even aggregate them with the other two prefix >routes, without anything incorrect happening in terms of information >represtation. > >If the routes overlap, its more complex. An example of this case is a >gateway with 5 trunk groups. It advertises 5 routes using trunk group >families, and 5 with prefix families. In this case, an LS would need to >know how these are correlated in order to properly manipulate them. I >think this is a recipe for disaster, and I would prefer to mandate the >non-overlapping case above. After much thought, some of us feel that providing three address families but allowing use one at a time is sufficient. So, the question here is: Can we come up with a reasonable example, that includes a TGREP/TRIP reachability flow and a call flow, describing how/why an actual customer may need this flexibility? Thx, Dhaval >-Jonathan R. >-- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PH: (973) 952-5000 >http://www.dynamicsoft.com > > >_______________________________________________ >IPTEL mailing list >IPTEL@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/iptel --=====================_4405444==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Please see some comments and questions inlined.


I don't think we need to standardize a window, but the spec should suggest that sufficiently large windows be used to provide a useful aggregated statistic.

We'll incorporate this.

Two comments.

First, I agree with Bob that we should allow the carrier attribute to be present in the trunk group address family. There was another comment to the list regarding that.

Will do that. Also, we are thinking of proposing to allow for T attribute to be present in C address family.


I think we can allow a mix, so long as the meaning of this is well defined. One possible model is that there is no overlap. So, if a gateway has 5 trunk groups, it can advertise three of them using trunk group address family, and the other two using prefix address families. This would allow for an LS to convert the three trunk group family routes to prefix routes, and then even aggregate them with the other two prefix routes, without anything incorrect happening in terms of information represtation.

If the routes overlap, its more complex. An example of this case is a gateway with 5 trunk groups. It advertises 5 routes using trunk group families, and 5 with prefix families. In this case, an LS would need to know how these are correlated in order to properly manipulate them. I think this is a recipe for disaster, and I would prefer to mandate the non-overlapping case above.

After much thought, some of us feel that providing three address families but allowing use one at a time is
sufficient.

So, the question here is: Can we come up with a reasonable example, that includes a TGREP/TRIP reachability
flow and a call flow, describing how/why an actual  customer may need this flexibility?

Thx,
Dhaval



-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist           &= nbsp;            = ; First Floor
dynamicsoft           = ;            &nb= sp;     East Hanover, NJ 07936
jdrosen@dynamicsoft.com         = ;        FAX: (973) 952-5050
http://www.jdrosen.net    = ;             PH:  (973) 952-5000
http://www.dynamicsoft.com


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel --=====================_4405444==_.ALT-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Sep 26 16:03:58 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20053 for ; Thu, 26 Sep 2002 16:03:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8QJoa203330; Thu, 26 Sep 2002 15:50:41 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8QJjK203291 for ; Thu, 26 Sep 2002 15:45:20 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g8QJjKhN012223 for ; Thu, 26 Sep 2002 15:45:20 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 1C18C443A6; Thu, 26 Sep 2002 15:45:15 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id E4DDA443A4 for ; Thu, 26 Sep 2002 15:45:14 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g8QJjDa26286 for ; Thu, 26 Sep 2002 15:45:13 -0400 (EDT) Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by dusty; Thu Sep 26 15:45:12 EDT 2002 Received: from mira-sjc5-8.cisco.com (IDENT:mirapoint@mira-sjc5-8.cisco.com [171.71.163.31]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8QJj3Ha017821; Thu, 26 Sep 2002 12:45:04 -0700 (PDT) Received: from cisco.com (dhcp-128-107-139-165.cisco.com [128.107.139.165]) by mira-sjc5-8.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAH30546; Thu, 26 Sep 2002 12:44:29 -0700 (PDT) Message-ID: <3D9363BD.CC3D03B4@cisco.com> From: Anirudh Sahoo X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dhaval Shah Cc: Jonathan Rosenberg , bpenfield@acmepacket.com, iptel@lists.bell-labs.com Subject: Re: [IPTEL] draft-ietf-iptel-trip-gw-00.txt has been posted References: <3D07C83D.422AFEBB@cisco.com> <4.3.2.7.2.20020926104404.0410e940@mira-sjc5-5.cisco.com> Content-Type: multipart/alternative; boundary="------------6D7CF4B0BED040ECBE5FDF6E" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 26 Sep 2002 12:45:02 -0700 --------------6D7CF4B0BED040ECBE5FDF6E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, Regarding whether to allow advertisement of more than addr fam or not, I feel we should allow advertisement of multiple addr fam as long as the routes do not overlap. There may be scenarios where it is more efficient to send non-overlapping routes in multiple address families. One case could be where a gateway is managed in such a way that some trunks do not have a carrier associated with them and some do. In this scenario it is more efficient to send both T and C family. Otherwise, if we put restriction for one family advertisement, then T family advertisement may be used (with C as attr). Then at the LS, to get carrier level resource information, the LS has to compute it from the T destination routes. So if we allow advertisement of non-overlapping multiple addr fam, then implementors will have flexibility to do whichever way they deem appropriate for their case. Other case could be where a gateway which has some analog (fxs) ports as well as some digital trunks. In this case, for fxs port, only the reachability info is enough, resource info is not important. So those could be advertised as prefix (e.g. e164) family. But for digital trunks since accurate resource reporting is important, a T family will be suitable. Since allowing advertisement of multiple address family without overlapping routes seems to have no adverse effect and at the same time provides the flexibility in cases described above, I feel that the draft should allow that. Otherwise, it will become restrictive for the above scenarios. Dhaval Shah wrote: > > Please see some comments and questions inlined. > > > >> I don't think we need to standardize a window, but the spec should >> suggest that sufficiently large windows be used to provide a useful >> aggregated statistic. > > > We'll incorporate this. > > >> Two comments. >> >> First, I agree with Bob that we should allow the carrier attribute >> to be present in the trunk group address family. There was another >> comment to the list regarding that. > > > Will do that. Also, we are thinking of proposing to allow for T > attribute to be present in C address family. > > > >> I think we can allow a mix, so long as the meaning of this is well >> defined. One possible model is that there is no overlap. So, if a >> gateway has 5 trunk groups, it can advertise three of them using >> trunk group address family, and the other two using prefix address >> families. This would allow for an LS to convert the three trunk >> group family routes to prefix routes, and then even aggregate them >> with the other two prefix routes, without anything incorrect >> happening in terms of information represtation. >> >> If the routes overlap, its more complex. An example of this case is >> a gateway with 5 trunk groups. It advertises 5 routes using trunk >> group families, and 5 with prefix families. In this case, an LS >> would need to know how these are correlated in order to properly >> manipulate them. I think this is a recipe for disaster, and I would >> prefer to mandate the non-overlapping case above. > > > After much thought, some of us feel that providing three address > families but allowing use one at a time is > sufficient. > > So, the question here is: Can we come up with a reasonable example, > that includes a TGREP/TRIP reachability > flow and a call flow, describing how/why an actual customer may need > this flexibility? > > Thx, > Dhaval > > > > >> -Jonathan R. >> -- >> Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue >> Chief Scientist First Floor >> dynamicsoft East Hanover, NJ 07936 >> jdrosen@dynamicsoft.com FAX: (973) 952-5050 >> http://www.jdrosen.net PH: (973) 952-5000 >> http://www.dynamicsoft.com >> >> >> _______________________________________________ >> IPTEL mailing list >> IPTEL@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/iptel > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Name : Anirudh Sahoo | | US mail : | | email : asahoo@cisco.com | | 170 W. Tasman Dr| | Tel : 408-525-4508 ||| ||| M/S: SJC21/2 | | Fax : 408-526-8521 ||||| ||||| San Jose, | | ..:|||||||:...:|||||||:.. CA - 95134 | | Cisco Systems Inc. | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------6D7CF4B0BED040ECBE5FDF6E Content-Type: text/html; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by sj-msg-core-2.cisco.com id g8QJj3Ha017821 Content-Transfer-Encoding: quoted-printable All,
    Regarding whether to allow advertisement of more than addr fam
or not, I feel we should allow advertisement of multiple addr fam
as long as the routes do not overlap. There may be scenarios where
it is more efficient to send non-overlapping routes in multiple
address families.
    One case could be where a gateway is managed in such a way
that some trunks do not have a carrier associated with them and some
do. In this scenario it is more efficient to send both T and C family.
Otherwise, if we put restriction for one family advertisement, then
T family advertisement may be used (with C as attr).
Then at the LS, to get carrier
level resource information, the LS has to compute it from the T
destination routes. So if we allow advertisement of non-overlapping
multiple addr fam, then implementors will have flexibility to
do whichever way they deem appropriate for their case.
    Other case could be where a gateway which has some
analog (fxs) ports as well as some digital trunks. In this case, for
fxs port, only the reachability info is enough, resource info is
not important. So those could be advertised as prefix (e.g. e164)
family. But for digital trunks since accurate resource reporting is
important, a T family will be suitable.
    Since allowing advertisement of multiple address family without
overlapping routes seems to have no adverse effect and at the same
time provides the flexibility in cases described above, I feel that
the draft should allow that. Otherwise, it will become restrictive for
the above scenarios.

Dhaval Shah wrote:

 
Please see some comments and questions inlined.
 
 
I don't think we need to sta= ndardize a window, but the spec should suggest that sufficiently large windows be used to provide a useful aggregated statistic.


We'll incorporate this.
 

Two comments.

First, I agree with Bob that we should allow the carri= er attribute to be present in the trunk group address family. There was anot= her comment to the list regarding that.


Will do that. Also, we are thinking of proposing t= o allow for T attribute to be present in C address family.
 
 

I think we can allow a mix, = so long as the meaning of this is well defined. One possible model is that there is no overlap. So, if a gateway has 5 trunk groups, it can advertis= e three of them using trunk group address family, and the other two using prefix address families. This would allow for an LS to convert the three trunk group family routes to prefix routes, and then even aggregate them with the other two prefix routes, without anything incorrect happening in terms of information represtation.

If the routes overlap, its more complex. An example of this case is a gateway with 5 trunk groups. It advertises 5 routes using trunk group families, and 5 with prefix families. In this case, an LS wou= ld need to know how these are correlated in order to properly manipulate the= m. I think this is a recipe for disaster, and I would prefer to mandate the non-overlapping case above.


After much thought, some of us feel that providing three address families but allowing use one at a time is
sufficient.

So, the question here is: Can we come up with a reason= able example, that includes a TGREP/TRIP reachability
flow and a call flow, describing how/why an actual&nb= sp; customer may need this flexibility?

Thx,
Dhaval
 
 
 

-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.    &= nbsp;       72 Eagle Rock Avenue
Chief Scientist      &n= bsp;           &nb= sp;      First Floor
dynamicsoft       =             &= nbsp;         East Hanover, NJ 07936
jdrosen@dynamicsoft.com     =             FAX: (973) 952-5050
http://www.jdrosen.ne= t            =     PH:  (973) 952-5000
http://www.dynamicsoft.com
 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/i= ptel

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Name :  Anirudh Sahoo       |&nb= sp;          |       US mail :    &n= bsp;  |
| email : asahoo@cisco.com    |    = ;       |       170 W. Tasman Dr|
| Tel :   408-525-4508       |||         |||   =    M/S: SJC21/2    |
| Fax :   408-526-8521      |||||&= nbsp;      |||||     San Jose,     &nbs= p; |
|           &n= bsp;           ..:|||||||:...:|||||||:.. CA - 95134      |
|           &n= bsp;           &nb= sp;   Cisco Systems Inc.         &= nbsp;          |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  --------------6D7CF4B0BED040ECBE5FDF6E-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Sep 26 16:25:39 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20782 for ; Thu, 26 Sep 2002 16:25:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8QKBY203593; Thu, 26 Sep 2002 16:11:34 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8QK5Z203530 for ; Thu, 26 Sep 2002 16:05:35 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g8QK5YhN012557 for ; Thu, 26 Sep 2002 16:05:35 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id BA590443A6; Thu, 26 Sep 2002 16:05:29 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 8ED3F443A4 for ; Thu, 26 Sep 2002 16:05:29 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g8QK5RI55549 for ; Thu, 26 Sep 2002 16:05:28 -0400 (EDT) Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by dusty; Thu Sep 26 16:05:27 EDT 2002 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8QK5J1X007996; Thu, 26 Sep 2002 13:05:19 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8QK5IZc003526; Thu, 26 Sep 2002 13:05:18 -0700 (PDT) Received: from DHAVAL-W2K2.cisco.com (dhcp-128-107-209-98.cisco.com [128.107.209.98]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA18229; Thu, 26 Sep 2002 13:05:16 -0700 (PDT) Message-Id: <4.3.2.7.2.20020926125626.041fc6f0@mira-sjc5-5.cisco.com> X-Sender: dhaval@mira-sjc5-5.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Anirudh Sahoo From: Dhaval Shah Subject: Re: [IPTEL] draft-ietf-iptel-trip-gw-00.txt has been posted Cc: Jonathan Rosenberg , bpenfield@acmepacket.com, iptel@lists.bell-labs.com In-Reply-To: <3D9363BD.CC3D03B4@cisco.com> References: <3D07C83D.422AFEBB@cisco.com> <4.3.2.7.2.20020926104404.0410e940@mira-sjc5-5.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_12294348==_.ALT" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 26 Sep 2002 13:05:16 -0700 --=====================_12294348==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Anirudh, At 12:45 PM 9/26/2002 -0700, Anirudh Sahoo wrote: >All, > Regarding whether to allow advertisement of more than addr fam >or not, I feel we should allow advertisement of multiple addr fam >as long as the routes do not overlap. There may be scenarios where >it is more efficient to send non-overlapping routes in multiple >address families. > One case could be where a gateway is managed in such a way >that some trunks do not have a carrier associated with them and some >do. In this scenario it is more efficient to send both T and C family. >Otherwise, if we put restriction for one family advertisement, then >T family advertisement may be used (with C as attr). Right. We thought about this and felt it could be covered by T with attr C. Not sure what you mean by more efficient and whether it buys us much. >Then at the LS, to get carrier >level resource information, the LS has to compute it from the T >destination routes. So if we allow advertisement of non-overlapping >multiple addr fam, then implementors will have flexibility to >do whichever way they deem appropriate for their case. Any concrete examples? In general, there are many other ways we could add flexibility in the protocol as a whole but I guess we try to measure against potential of real use since else flexibility can also cause confusion/misconfigs etc. > Other case could be where a gateway which has some >analog (fxs) ports as well as some digital trunks. In this case, for >fxs port, only the reachability info is enough, resource info is >not important. So those could be advertised as prefix (e.g. e164) >family. But for digital trunks since accurate resource reporting is >important, a T family will be suitable. If resource info. is not important in certain cases, then don't include it. T family can cover both cases in this case. > Since allowing advertisement of multiple address family without >overlapping routes seems to have no adverse effect and at the same >time provides the flexibility in cases described above, I feel that Please see above. It'd be great if you could describe the concrete customer scenario in mind accompanied with reachability and call flows, if any.. Thx, Dhaval, Manjunath and Rajneesh >the draft should allow that. Otherwise, it will become restrictive for >the above scenarios. > >Dhaval Shah wrote: >> >>Please see some comments and questions inlined. >> >> >>>I don't think we need to standardize a window, but the spec should >>>suggest that sufficiently large windows be used to provide a useful >>>aggregated statistic. >> >> >>We'll incorporate this. >> >>>Two comments. >>> >>>First, I agree with Bob that we should allow the carrier attribute to be >>>present in the trunk group address family. There was another comment to >>>the list regarding that. >> >> >>Will do that. Also, we are thinking of proposing to allow for T attribute >>to be present in C address family. >> >> >>>I think we can allow a mix, so long as the meaning of this is well >>>defined. One possible model is that there is no overlap. So, if a >>>gateway has 5 trunk groups, it can advertise three of them using trunk >>>group address family, and the other two using prefix address families. >>>This would allow for an LS to convert the three trunk group family >>>routes to prefix routes, and then even aggregate them with the other two >>>prefix routes, without anything incorrect happening in terms of >>>information represtation. >>> >>>If the routes overlap, its more complex. An example of this case is a >>>gateway with 5 trunk groups. It advertises 5 routes using trunk group >>>families, and 5 with prefix families. In this case, an LS would need to >>>know how these are correlated in order to properly manipulate them. I >>>think this is a recipe for disaster, and I would prefer to mandate the >>>non-overlapping case above. >> >> >>After much thought, some of us feel that providing three address families >>but allowing use one at a time is >>sufficient. >> >>So, the question here is: Can we come up with a reasonable example, that >>includes a TGREP/TRIP reachability >>flow and a call flow, describing how/why an actual customer may need >>this flexibility? >> >>Thx, >>Dhaval >> >> >> >>>-Jonathan R. >>>-- >>>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue >>>Chief Scientist First Floor >>>dynamicsoft East Hanover, NJ 07936 >>>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>>http://www.jdrosen.net PH: (973) 952-5000 >>>http://www.dynamicsoft.com >>> >>> >>>_______________________________________________ >>>IPTEL mailing list >>>IPTEL@lists.bell-labs.com >>>http://lists.bell-labs.com/mailman/listinfo/iptel > >-- >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >| Name : Anirudh Sahoo | | US mail : | >| email : asahoo@cisco.com | | 170 W. Tasman Dr| >| Tel : 408-525-4508 ||| ||| M/S: SJC21/2 | >| Fax : 408-526-8521 ||||| ||||| San Jose, | >| ..:|||||||:...:|||||||:.. CA - 95134 | >| Cisco Systems Inc. | >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > --=====================_12294348==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Anirudh,

At 12:45 PM 9/26/2002 -0700, Anirudh Sahoo wrote:

All,
    Regarding whether to allow advertisement of more than addr fam
or not, I feel we should allow advertisement of multiple addr fam
as long as the routes do not overlap. There may be scenarios where
it is more efficient to send non-overlapping routes in multiple
address families.
    One case could be where a gateway is managed in such a way
that some trunks do not have a carrier associated with them and some
do. In this scenario it is more efficient to send both T and C family.
Otherwise, if we put restriction for one family advertisement, then=20
T family advertisement may be used (with C as attr).

Right. We thought about this and felt it could be covered by T with attr C.
Not sure what you mean by more efficient and whether it buys us much.

Then at the LS, to get carrier
level resource information, the LS has to compute it from the T
destination routes. So if we allow advertisement of non-overlapping=20
multiple addr fam, then implementors will have flexibility to
do whichever way they deem appropriate for their case.

Any concrete examples? In general, there are many other ways we could
add flexibility in the protocol as a whole but I guess we try to measure against
potential of real use since else flexibility can also cause confusion/misconfigs etc.

    Other case could be where a gateway which has some
analog (fxs) ports as well as some digital trunks. In this case, for
fxs port, only the reachability info is enough, resource info is
not important. So those could be advertised as prefix (e.g. e164)
family. But for digital trunks since accurate resource reporting is=20
important, a T family will be suitable.

If resource info. is not important in certain cases, then don't include it.
T family can cover both cases in this case.

    Since allowin= g advertisement of multiple address family without
overlapping routes seems to have no adverse effect and at the same
time provides the flexibility in cases described above, I feel that

Please see above.

It'd be great if you could describe the concrete customer scenario in mind accompanied
with reachability and call flows, if any..

Thx,
Dhaval, Manjunath and Rajneesh

the draft should allow that. Otherwise, it will become restrictive for
the above scenarios.

Dhaval Shah wrote:
 
Please see some comments and questions inlined.
 
 
I don't think we need to standardize a window, but the spec should suggest that sufficiently large windows be used to provide a useful aggregated statistic.


We'll incorporate this.
 
Two comments.

First, I agree with Bob that we should allow the carrier attribute to be present in the trunk group address family. There was another comment to the list regarding that.


Will do that. Also, we are thinking of proposing to allow for T attribute to be present in C address family.
 
 
I think we can allow a mix, so long as the meaning of this is well defined. One possible model is that there is no overlap. So, if a gateway has 5 trunk groups, it can advertise three of them using trunk group address family, and the other two using prefix address families. This would allow for an LS to convert the three trunk group family routes to prefix routes, and then even aggregate them with the other two prefix routes, without anything incorrect happening in terms of information represtation.

If the routes overlap, its more complex. An example of this case is a gateway with 5 trunk groups. It advertises 5 routes using trunk group families, and 5 with prefix families. In this case, an LS would need to know how these are correlated in order to properly manipulate them. I think this is a recipe for disaster, and I would prefer to mandate the non-overlapping case above.


After much thought, some of us feel that providing three address families but allowing use one at a time is
sufficient.

So, the question here is: Can we come up with a reasonable example, that includes a TGREP/TRIP reachability
flow and a call flow, describing how/why an actual  customer may need this flexibility?

Thx,
Dhaval
 
 
 
-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist           &= nbsp;            = ; First Floor
dynamicsoft           = ;            &nb= sp;     East Hanover, NJ 07936
jdrosen@dynamicsoft.com         = ;        FAX: (973) 952-5050
http://www.jdrosen.net     = ;          PH:  (973) 952-5000
http://www.dynami= csoft.com
 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Name :  Anirudh Sahoo      = |          = |       US mail= :       |
| email : asahoo@cisco.com   = |          = |       170 W. Tasman Dr|
| Tel :   408-525-4508      = |||        = |||      M/S: SJC21/2    |
| Fax :   408-526-8521     = |||||       |||||     San= Jose,       |
|            &nb= sp;         = ..:|||||||:...:|||||||:.. CA - 95134      |
|            &nb= sp;            &= nbsp; Cisco Systems= Inc.            = ;        |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
--=====================_12294348==_.ALT-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel