From http-state-admin@lists.bell-labs.com Mon Oct 1 06:03:38 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09676 for ; Mon, 1 Oct 2001 06:03:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BCEE644339 for ; Mon, 1 Oct 2001 05:00:27 -0400 (EDT) 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: http-state-admin@lists.bell-labs.com Errors-To: http-state-admin@lists.bell-labs.com X-BeenThere: http-state@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Message-Id: <20011001090027.BCEE644339@lists.bell-labs.com> Date: Mon, 1 Oct 2001 05:00:27 -0400 (EDT) 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 Gfcn http://lists.bell-labs.com/mailman/options/iptel/iptel-archive%40lists.ietf.org From iptel-admin@lists.bell-labs.com Mon Oct 1 13:48:18 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24996 for ; Mon, 1 Oct 2001 13:48:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 931DD4433A; Mon, 1 Oct 2001 12:45:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mail1.dynamicsoft.com (unknown [63.113.40.10]) by lists.bell-labs.com (Postfix) with ESMTP id C4B4944337 for ; Mon, 1 Oct 2001 12:44:59 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f91HlD8P025395 for ; Mon, 1 Oct 2001 13:47:13 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <4A0SMXXQ>; Mon, 1 Oct 2001 13:48:15 -0400 Message-ID: From: Jonathan Rosenberg To: "'iptel@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [IPTEL] the silence is deafening... 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 1 Oct 2001 13:48:14 -0400 Folks, Its been about 3 weeks since our call for proposals for "gateway registration" drafts ended. We actually have THREE proposals on the table: http://search.ietf.org/internet-drafts/draft-roy-iptel-gw-server-discovery-0 0.txt http://search.ietf.org/internet-drafts/draft-roy-iptel-itrp-00.txt http://search.ietf.org/internet-drafts/draft-rs-trip-gw-02.txt http://search.ietf.org/internet-drafts/draft-zhao-iptel-gwloc-slp-01.txt However, there has not been a single email post on this list with comments or questions. I'm not sure how to interpret that. Perhaps people are just busy (always true), or perhaps this is not important enough for anyone to take the time to focus on. However, if it is something that people do not feel is important enough to focus on, to the extent that they are willing to post comments or push their proposals, then I could only conclude that it is not something interesting enough to keep on the charter. I would be perfectly happy to finish the MIB and close down the group; I certainly have plenty of other things to do. So, please do comment on these, and make your opinions known. If there is no discussion within another two weeks, I will consider this consensus to remove the item from the charter and begin the process to make that happen. -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 Mon Oct 1 14:39:17 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26409 for ; Mon, 1 Oct 2001 14:39:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E910844348; Mon, 1 Oct 2001 13:36:01 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by lists.bell-labs.com (Postfix) with ESMTP id 73E8C4433A for ; Mon, 1 Oct 2001 13:35:42 -0400 (EDT) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id OAA06191; Mon, 1 Oct 2001 14:38:55 -0400 (EDT) Message-ID: <3BB8B83F.11BF740A@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] the silence is deafening... References: Content-Type: text/plain; charset=us-ascii 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 01 Oct 2001 14:38:55 -0400 Content-Transfer-Encoding: 7bit I'll bite :-) One question is whether we need one solution or whether different solutions have different applications and trade-offs. After all, we have RIPv2, OSPF, IS-IS and some vendor-proprietary protocols (as well as simpler router discovery and advertisement via ICMP, IGMP and DHCP) as interior/intra-domain routing protocols and BGPv4 as exterior/inter-domain. Also, as with routing protocols, availability of broadcast/multicast plays a role here. I would like to be able to optimize efficiency (or reduce complexity) if multicast is available. As one real-life example I happen to be familiar with, Internet2 is multicast-enabled and is looking at how to distribute gateway information in the future. Also, the complexity of standardizing these things differ. In some cases, it's a new protocol, in others a profile, in the third mainly a new data structure (template). It might be helpful if the proponents/authors of each proposal could abstract their proposal into a common set of properties, of which I suggested a few above. (I'm sure there are many others I missed.) This will tell us if the proposals are different mainly because they make different assumptions on infrastructure and usage, and thus likely will be complementary, or whether they are solving the same problem in the same space. From what I can tell, the number of parameters for each gateway appears to be fairly small, so that translation between the schemes or to an exterior scheme is reasonably simple. It is also not clear to me that just blindly "exporting" the information wholesale to an inter-domain scheme is desirable. If you consider the Internet2 example above, while universities might make their facilities available in a "peering"/mutual-aid fashion (no pay) to other universities, they may have much more restrictive policies as to who gets to see what once it leaves Internet2. Jonathan Rosenberg wrote: > > Folks, > > Its been about 3 weeks since our call for proposals for "gateway > registration" drafts ended. We actually have THREE proposals on the table: > > http://search.ietf.org/internet-drafts/draft-roy-iptel-gw-server-discovery-0 > 0.txt > http://search.ietf.org/internet-drafts/draft-roy-iptel-itrp-00.txt > > http://search.ietf.org/internet-drafts/draft-rs-trip-gw-02.txt > > http://search.ietf.org/internet-drafts/draft-zhao-iptel-gwloc-slp-01.txt > > However, there has not been a single email post on this list with comments > or questions. I'm not sure how to interpret that. Perhaps people are just > busy (always true), or perhaps this is not important enough for anyone to > take the time to focus on. However, if it is something that people do not > feel is important enough to focus on, to the extent that they are willing to > post comments or push their proposals, then I could only conclude that it is > not something interesting enough to keep on the charter. I would be > perfectly happy to finish the MIB and close down the group; I certainly have > plenty of other things to do. So, please do comment on these, and make your > opinions known. If there is no discussion within another two weeks, I will > consider this consensus to remove the item from the charter and begin the > process to make that happen. > -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Oct 1 17:37:19 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01904 for ; Mon, 1 Oct 2001 17:37:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 37EFB44337; Mon, 1 Oct 2001 16:34:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 4159C44336 for ; Mon, 1 Oct 2001 16:33:01 -0400 (EDT) Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f91LaG314356; Mon, 1 Oct 2001 17:36:16 -0400 (EDT) Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id RAA23323; Mon, 1 Oct 2001 17:36:29 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Oct 2001 17:36:15 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: "Henning G. Schulzrinne" , Jonathan Rosenberg Cc: "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] the silence is deafening... MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 1 Oct 2001 17:36:14 -0400 Per Henning's suggestions, I am adding the following . . . The common properties that all intra-ITAD (intra-domain) proposals need to have: 1. A single protocol 2. Gateways can be Telephony (e.g., E.164) GWs and/or SIP-H.323 GWs (E.164, Email IDs, URL IDs) 3. Communication environments for address resolutions: a. GWs <-> (Location/Route) Server and b. (Location/Route) Server <-> (Location/Route) Server 4. Functionalities of the protocol needed: Discovery, Registration, Confirmation (and Selective Updates of addresses, and Keep-Alive messages, and Error-Notifications for efficiency reason). 5. Scalability of the protocol (e.g., Multicasting using connectionless transport [e.g., UDP]) 6. Possible Extensions for Value-added features (e.g., capability negotiations, alternate peers for back-up, capacity, policy, QOS) In short, the alternate proposals that we have can be described as follows: A. ITRP (R. Roy) 1. The proposed ITRP protocol satisfies the above properties. ITRP has also the properties what TRIP-GW or GW-SLP proposal also does. Briefly, it appears that both TRIP-GW and GW-SLP proposal may require more than one protocol to satisfy the needs while a single ITRP protocol will be able to do the same. 2. It has the capability for Discovery, Registration, Confirmation, Selective Updates of addresses, Keep-Alive messages, and Error-Notifications. The communication can be: a. GWs <-> (Location/Route) Server and b. (Location/Route) Server <-> (Location/Route) Server. 3. It has the ability to restrict the communications among the gateways and servers as needed: a. Many-to-One, b. One-to-Many, (and c. Many-to-Many). 4. Both UDP and TCP transport can be used as needed. Unlike TRIP-GW, it can use multicasting using for updates among the servers. 5. A server will also be able to aggregate the address information for scalability and efficiency and may be able to send the same to all other servers. 6. Value-added features like capability negotiations, alternate peers for back-up, capacity, etc. can be used. 7. The address resolutions can be provided for Telephony (e.g., E.164) GWs and/or SIP-H.323 GWs (E.164, Email IDs, URL IDs). 8. The proposed message formats of ITRP are similar to those of TRIP. B. TRIP-GW (J. Rosenberg, et al) 1. The TRIP-GW proposal needs another protocol for discovery of the gateways. Moreover, connectionless transport (e.g., UDP) is efficient for discovery protocols between the gateways and the servers (but it uses connection-oriented TCP protocol). 2. For servers to server communications, this protocol uses connection-oriented TCP transport protocol. When selective updates are made by the gateways to the any server, the said server uses flooding (or limited broadcast) to update that information among all other servers, instead of using more efficient multicasting (over the UDP transport for example). 3. TRIP-GW message sets are inherently complex because it has been designed to solve more complex problems like route aggregation and route propagation, which are not needed for the intra-ITAD communications. 4. In addition to Telephony numbers, we need to provide address resolutions for Email Ids, URL Ids, etc. as well. These items are yet to address by the TRIP-GW. C. GW-SLP (W. Zhao, et al) 1. The GW-SLP proposal extends the SLP protocol for discovery and registration, but there exists a many-to-many relationship between the gateways and servers. This may pose problems in managing the large networks. In ITRP proposal, it can be restricted such that a set of GWs can be communicating only with a single server. 2. The GW-SLP proposal does not specify communications among the servers and, GWs are required to communicate with all servers using multicasting if multiple servers are deployed. That is, a new protocol may be needed if the server-to-server communications are required. (Both ITRP and GW-TRIP provide mechanisms for server to server communications.) 3. No mechanism is defined in the GW-SLP proposal if selective updates are needed because it is not efficient to send the register message again and again for simple updates. 4. A server may also need to aggregate the address information and may require to send the same to all other servers and, there is a need for communication among the servers (as suggested in ITRP and TRIP-GW). In GW-SLP proposal, no protocol has been suggested for the server-to-server communications. The above note provides a brief summary of all proposals. Comments will be appreciated. Best regards, Radhika R. Roy rrroy@att.com -----Original Message----- From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Monday, October 01, 2001 2:39 PM To: Jonathan Rosenberg Cc: 'iptel@lists.bell-labs.com' Subject: Re: [IPTEL] the silence is deafening... I'll bite :-) One question is whether we need one solution or whether different solutions have different applications and trade-offs. After all, we have RIPv2, OSPF, IS-IS and some vendor-proprietary protocols (as well as simpler router discovery and advertisement via ICMP, IGMP and DHCP) as interior/intra-domain routing protocols and BGPv4 as exterior/inter-domain. Also, as with routing protocols, availability of broadcast/multicast plays a role here. I would like to be able to optimize efficiency (or reduce complexity) if multicast is available. As one real-life example I happen to be familiar with, Internet2 is multicast-enabled and is looking at how to distribute gateway information in the future. Also, the complexity of standardizing these things differ. In some cases, it's a new protocol, in others a profile, in the third mainly a new data structure (template). It might be helpful if the proponents/authors of each proposal could abstract their proposal into a common set of properties, of which I suggested a few above. (I'm sure there are many others I missed.) This will tell us if the proposals are different mainly because they make different assumptions on infrastructure and usage, and thus likely will be complementary, or whether they are solving the same problem in the same space. From what I can tell, the number of parameters for each gateway appears to be fairly small, so that translation between the schemes or to an exterior scheme is reasonably simple. It is also not clear to me that just blindly "exporting" the information wholesale to an inter-domain scheme is desirable. If you consider the Internet2 example above, while universities might make their facilities available in a "peering"/mutual-aid fashion (no pay) to other universities, they may have much more restrictive policies as to who gets to see what once it leaves Internet2. Jonathan Rosenberg wrote: > > Folks, > > Its been about 3 weeks since our call for proposals for "gateway > registration" drafts ended. We actually have THREE proposals on the table: > > http://search.ietf.org/internet-drafts/draft-roy-iptel-gw-server-discovery-0 > 0.txt > http://search.ietf.org/internet-drafts/draft-roy-iptel-itrp-00.txt > > http://search.ietf.org/internet-drafts/draft-rs-trip-gw-02.txt > > http://search.ietf.org/internet-drafts/draft-zhao-iptel-gwloc-slp-01.txt > > However, there has not been a single email post on this list with comments > or questions. I'm not sure how to interpret that. Perhaps people are just > busy (always true), or perhaps this is not important enough for anyone to > take the time to focus on. However, if it is something that people do not > feel is important enough to focus on, to the extent that they are willing to > post comments or push their proposals, then I could only conclude that it is > not something interesting enough to keep on the charter. I would be > perfectly happy to finish the MIB and close down the group; I certainly have > plenty of other things to do. So, please do comment on these, and make your > opinions known. If there is no discussion within another two weeks, I will > consider this consensus to remove the item from the charter and begin the > process to make that happen. > -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ 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 Mon Oct 1 18:13:20 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02843 for ; Mon, 1 Oct 2001 18:13:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1AD394433F; Mon, 1 Oct 2001 17:10:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from integraonline.com (inet-1a-bvtn.integraonline.com [206.163.82.156]) by lists.bell-labs.com (Postfix) with SMTP id 56A9244336 for ; Mon, 1 Oct 2001 17:09:05 -0400 (EDT) Received: (qmail 27835 invoked from network); 1 Oct 2001 22:12:26 -0000 Received: from fw-1-bvtn.integratelecom.com (HELO beaexch2.ads.integratelecom.com) ([206.163.82.5]) (envelope-sender ) by inet-1a-bvtn.integraonline.com (qmail-ldap-1.03) with SMTP for ; 1 Oct 2001 22:12:26 -0000 Received: by beaexch2.ads.integratelecom.com with Internet Mail Service (5.5.2650.21) id ; Mon, 1 Oct 2001 15:12:22 -0700 Message-ID: From: "Anderson, Darby" To: "'Roy, Radhika R, ALCTA'" , "Henning G. Schulzrinne" , Jonathan Rosenberg Cc: "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] the silence is deafening... MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 1 Oct 2001 15:12:21 -0700 First of all, my appologies to thoose of whom that receive plural copies of this... I dont know if this is the place to stand at the fence with the boys comparing toys, and features of Johhny's,Joe's, and Suzy's cars, BUT... hypothetically IF I were a internet telephony service provider, I think I'd have to side with Roy's twist on the scenario, due to the updating mechanisms (Multicast UDP), in addition to the flexability of Voice G/W ~~> LocServ ~~> RouteServ (Softswitch?), as some carriers may wish to have selective avilability of their resources internally on their network, vs. externally to other networks (Thus easing the burden on security, and/or accounting aspects of their networks) really the only items I see that are currently unnessary are thoose having to due with URL's, but maybe Im missing part of the big picture somewhere? I suppose my only concerns as of present are: 1. Would this twist still be TRIP? 2. If so, would this add much more developement time for the devlopement of this protocol? 3. In reguards to Section A, Subsection 5, does this make provisions for redundancy/diversity of all network elements? (I.E. G/W's,LocServ,RouteServ,Etc.) "A server will also be able to aggregate the address information for scalability and efficiency and may be able to send the same to all other servers." -----Original Message----- From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] Sent: Monday, October 01, 2001 3:36 PM To: Henning G. Schulzrinne; Jonathan Rosenberg Cc: 'iptel@lists.bell-labs.com' Subject: RE: [IPTEL] the silence is deafening... Per Henning's suggestions, I am adding the following . . . The common properties that all intra-ITAD (intra-domain) proposals need to have: 1. A single protocol 2. Gateways can be Telephony (e.g., E.164) GWs and/or SIP-H.323 GWs (E.164, Email IDs, URL IDs) 3. Communication environments for address resolutions: a. GWs <-> (Location/Route) Server and b. (Location/Route) Server <-> (Location/Route) Server 4. Functionalities of the protocol needed: Discovery, Registration, Confirmation (and Selective Updates of addresses, and Keep-Alive messages, and Error-Notifications for efficiency reason). 5. Scalability of the protocol (e.g., Multicasting using connectionless transport [e.g., UDP]) 6. Possible Extensions for Value-added features (e.g., capability negotiations, alternate peers for back-up, capacity, policy, QOS) In short, the alternate proposals that we have can be described as follows: A. ITRP (R. Roy) 1. The proposed ITRP protocol satisfies the above properties. ITRP has also the properties what TRIP-GW or GW-SLP proposal also does. Briefly, it appears that both TRIP-GW and GW-SLP proposal may require more than one protocol to satisfy the needs while a single ITRP protocol will be able to do the same. 2. It has the capability for Discovery, Registration, Confirmation, Selective Updates of addresses, Keep-Alive messages, and Error-Notifications. The communication can be: a. GWs <-> (Location/Route) Server and b. (Location/Route) Server <-> (Location/Route) Server. 3. It has the ability to restrict the communications among the gateways and servers as needed: a. Many-to-One, b. One-to-Many, (and c. Many-to-Many). 4. Both UDP and TCP transport can be used as needed. Unlike TRIP-GW, it can use multicasting using for updates among the servers. 5. A server will also be able to aggregate the address information for scalability and efficiency and may be able to send the same to all other servers. 6. Value-added features like capability negotiations, alternate peers for back-up, capacity, etc. can be used. 7. The address resolutions can be provided for Telephony (e.g., E.164) GWs and/or SIP-H.323 GWs (E.164, Email IDs, URL IDs). 8. The proposed message formats of ITRP are similar to those of TRIP. B. TRIP-GW (J. Rosenberg, et al) 1. The TRIP-GW proposal needs another protocol for discovery of the gateways. Moreover, connectionless transport (e.g., UDP) is efficient for discovery protocols between the gateways and the servers (but it uses connection-oriented TCP protocol). 2. For servers to server communications, this protocol uses connection-oriented TCP transport protocol. When selective updates are made by the gateways to the any server, the said server uses flooding (or limited broadcast) to update that information among all other servers, instead of using more efficient multicasting (over the UDP transport for example). 3. TRIP-GW message sets are inherently complex because it has been designed to solve more complex problems like route aggregation and route propagation, which are not needed for the intra-ITAD communications. 4. In addition to Telephony numbers, we need to provide address resolutions for Email Ids, URL Ids, etc. as well. These items are yet to address by the TRIP-GW. C. GW-SLP (W. Zhao, et al) 1. The GW-SLP proposal extends the SLP protocol for discovery and registration, but there exists a many-to-many relationship between the gateways and servers. This may pose problems in managing the large networks. In ITRP proposal, it can be restricted such that a set of GWs can be communicating only with a single server. 2. The GW-SLP proposal does not specify communications among the servers and, GWs are required to communicate with all servers using multicasting if multiple servers are deployed. That is, a new protocol may be needed if the server-to-server communications are required. (Both ITRP and GW-TRIP provide mechanisms for server to server communications.) 3. No mechanism is defined in the GW-SLP proposal if selective updates are needed because it is not efficient to send the register message again and again for simple updates. 4. A server may also need to aggregate the address information and may require to send the same to all other servers and, there is a need for communication among the servers (as suggested in ITRP and TRIP-GW). In GW-SLP proposal, no protocol has been suggested for the server-to-server communications. The above note provides a brief summary of all proposals. Comments will be appreciated. Best regards, Radhika R. Roy rrroy@att.com -----Original Message----- From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Monday, October 01, 2001 2:39 PM To: Jonathan Rosenberg Cc: 'iptel@lists.bell-labs.com' Subject: Re: [IPTEL] the silence is deafening... I'll bite :-) One question is whether we need one solution or whether different solutions have different applications and trade-offs. After all, we have RIPv2, OSPF, IS-IS and some vendor-proprietary protocols (as well as simpler router discovery and advertisement via ICMP, IGMP and DHCP) as interior/intra-domain routing protocols and BGPv4 as exterior/inter-domain. Also, as with routing protocols, availability of broadcast/multicast plays a role here. I would like to be able to optimize efficiency (or reduce complexity) if multicast is available. As one real-life example I happen to be familiar with, Internet2 is multicast-enabled and is looking at how to distribute gateway information in the future. Also, the complexity of standardizing these things differ. In some cases, it's a new protocol, in others a profile, in the third mainly a new data structure (template). It might be helpful if the proponents/authors of each proposal could abstract their proposal into a common set of properties, of which I suggested a few above. (I'm sure there are many others I missed.) This will tell us if the proposals are different mainly because they make different assumptions on infrastructure and usage, and thus likely will be complementary, or whether they are solving the same problem in the same space. From what I can tell, the number of parameters for each gateway appears to be fairly small, so that translation between the schemes or to an exterior scheme is reasonably simple. It is also not clear to me that just blindly "exporting" the information wholesale to an inter-domain scheme is desirable. If you consider the Internet2 example above, while universities might make their facilities available in a "peering"/mutual-aid fashion (no pay) to other universities, they may have much more restrictive policies as to who gets to see what once it leaves Internet2. Jonathan Rosenberg wrote: > > Folks, > > Its been about 3 weeks since our call for proposals for "gateway > registration" drafts ended. We actually have THREE proposals on the table: > > http://search.ietf.org/internet-drafts/draft-roy-iptel-gw-server-discovery-0 > 0.txt > http://search.ietf.org/internet-drafts/draft-roy-iptel-itrp-00.txt > > http://search.ietf.org/internet-drafts/draft-rs-trip-gw-02.txt > > http://search.ietf.org/internet-drafts/draft-zhao-iptel-gwloc-slp-01.txt > > However, there has not been a single email post on this list with comments > or questions. I'm not sure how to interpret that. Perhaps people are just > busy (always true), or perhaps this is not important enough for anyone to > take the time to focus on. However, if it is something that people do not > feel is important enough to focus on, to the extent that they are willing to > post comments or push their proposals, then I could only conclude that it is > not something interesting enough to keep on the charter. I would be > perfectly happy to finish the MIB and close down the group; I certainly have > plenty of other things to do. So, please do comment on these, and make your > opinions known. If there is no discussion within another two weeks, I will > consider this consensus to remove the item from the charter and begin the > process to make that happen. > -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ 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 Mon Oct 1 18:27:18 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03410 for ; Mon, 1 Oct 2001 18:27:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D170B4434E; Mon, 1 Oct 2001 17:24:01 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by lists.bell-labs.com (Postfix) with ESMTP id 5B5364434D for ; Mon, 1 Oct 2001 17:23:27 -0400 (EDT) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id SAA19024; Mon, 1 Oct 2001 18:26:40 -0400 (EDT) Message-ID: <3BB8EDA0.8F12C2BB@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: "Roy, Radhika R, ALCTA" Cc: "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] the silence is deafening... References: Content-Type: text/plain; charset=us-ascii 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 01 Oct 2001 18:26:40 -0400 Content-Transfer-Encoding: 7bit "Roy, Radhika R, ALCTA" wrote: > > Per Henning's suggestions, I am adding the following . . . > > The common properties that all intra-ITAD (intra-domain) proposals need to > have: > > 1. A single protocol I don't understand this requirement. > > 2. Gateways can be Telephony (e.g., E.164) GWs and/or SIP-H.323 GWs (E.164, > Email IDs, URL IDs) > > 3. Communication environments for address resolutions: a. GWs <-> > (Location/Route) Server and b. (Location/Route) Server <-> (Location/Route) > Server This depends on a particular model of the world; I don't think that's a given. > > 4. Functionalities of the protocol needed: Discovery, Registration, > Confirmation (and Selective Updates of addresses, and Keep-Alive messages, > and Error-Notifications for efficiency reason). > > 5. Scalability of the protocol (e.g., Multicasting using connectionless > transport [e.g., UDP]) > > 6. Possible Extensions for Value-added features (e.g., capability > negotiations, alternate peers for back-up, capacity, policy, QOS) Just like for routing, depending on the complexity trade-offs, that may not be the right one. There is a reason, after all, that not everyone is running OSPF when router discovery is all you need. > > C. GW-SLP (W. Zhao, et al) > > 1. The GW-SLP proposal extends the SLP protocol for discovery and > registration, but there exists a many-to-many relationship between the > gateways and servers. This may pose problems in managing the large networks. I don't see the problem. SLP commonly deals with many clients that need resource information and with many services. > In ITRP proposal, it can be restricted such that a set of GWs can be > communicating only with a single server. > > 2. The GW-SLP proposal does not specify communications among the servers > and, GWs are required to communicate with all servers using multicasting if > multiple servers are deployed. That is, a new protocol may be needed if the > server-to-server communications are required. (Both ITRP and GW-TRIP provide > mechanisms for server to server communications.) That is bogus. DAs can communicate with each other, if that's the architecture selected. > > 3. No mechanism is defined in the GW-SLP proposal if selective updates are > needed because it is not efficient to send the register message again and > again for simple updates. I don't know what you mean by selective updates. You mean for individual prefixes? SLP has partial updates, if really needed. (Based on experience, it seems to be deprecated and little used in practice.) Supported or not, my suspicion is that the complexity is not worth it, given the issues of synchronization of new "listeners". In general, at least in SIP (and RSVP, for another example), we have made the choice of providing complete state information, rather than incremental state. How large do you anticipate advertisements to be? Inside a network, is the bandwidth efficiency an issue? > > 4. A server may also need to aggregate the address information and may > require to send the same to all other servers and, there is a need for > communication among the servers (as suggested in ITRP and TRIP-GW). In > GW-SLP proposal, no protocol has been suggested for the server-to-server > communications. Bogus. See above. You can do whatever aggregation you want, if that's necessary. Clearly, the aggregated version has to be distinguished (it's a different "service"), but I don't see the protocol problem. > > The above note provides a brief summary of all proposals. > > Comments will be appreciated. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Oct 1 19:20:19 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04389 for ; Mon, 1 Oct 2001 19:20:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 56A294433A; Mon, 1 Oct 2001 18:17:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by lists.bell-labs.com (Postfix) with ESMTP id 8489C44336 for ; Mon, 1 Oct 2001 18:16:11 -0400 (EDT) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id TAA21104; Mon, 1 Oct 2001 19:19:28 -0400 (EDT) Message-ID: <3BB8FA00.FE65E239@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: iptel@lists.bell-labs.com Cc: Weibin Zhao Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] Parameters for gateway advertisements 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 01 Oct 2001 19:19:28 -0400 Content-Transfer-Encoding: 7bit Beyond some notion of cost and maybe load or first-derivative of load, are there other (optional) parameters that that are of interest for gateways? One parameter commonly used to advertise international trunks is "answer seizure ratio" (ASR), which apparently provides some indication as to the loading of the system on the other side. Is this useful? Some other QOS measure such as (post-dial delay) PDD? -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Oct 2 00:50:24 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12795 for ; Tue, 2 Oct 2001 00:50:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 30E9D44337; Mon, 1 Oct 2001 23:47:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.130]) by lists.bell-labs.com (Postfix) with ESMTP id 45A1A44336 for ; Mon, 1 Oct 2001 23:46:54 -0400 (EDT) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Oct 2001 21:49:17 -0700 Received: from rwcjfmule01 (adsl-64-169-17-213.dsl.snfc21.pacbell.net [64.169.17.213]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TYCR1SLQ; Mon, 1 Oct 2001 21:49:14 -0700 From: Jean-Francois Mule Reply-To: Jean-Francois Mule To: "'Jonathan Rosenberg'" , iptel@lists.bell-labs.com Subject: RE: [IPTEL] the silence is deafening... Message-ID: <000901c14afd$ae772630$d511a940@rwcjfmule01> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 1 Oct 2001 21:49:53 -0700 Content-Transfer-Encoding: 7bit I will bark ;) without having reviewed the proposals in great details, here are some quick practical comments in no particular order: - in draft-rs-trip-gw-02.txt, REQ 6, I definitely agree that the proxy or RS will be centrally programmed with the route/cost(s) information and that it is a bad idea to configure the gateways with this. For e.g., applications where route/cost params depend on time of day - in draft-rs-trip-gw-02.txt, REQ 8, why is it stated that (may be) !REQ6 => !REQ8 !! I believe that extensible attributes are necessary and they can indeed be characteristics of either the gateway (a gateway identifier or some info about gateway groupings used to span virtual gateways across multiple physical gateways or trunks), the gateway trunks (1 physical gateway with several trunks going to multiple service providers for redundancy or cost routing), or the routes themselves. - in draft-rs-trip-gw-02.txt, i believe it would be useful to have a means for the proxy to specify the thresholds the gateway should use to report on "out of capacity", "capacity available". In some conservative networks, you may not want to load your gateways more than 80% of its capacity to share the load but in traffic peaks, you may want to change it to 98% for example so having the proxy centrally dictate this parameter could be very useful. Not sure how to express that in trip-gw. - in draft-zhao-iptel-gwloc-slp-01.txt, it is proposed that "the location server needs to know the capacity of each gateway." in draft-rs-trip-gw-02.txt, i see a slightly different requirement in REQ4. While some vendors would probably like to know the total gateway capacity or how many ds0s are being managed in a network (for licensing for e.g.), I do not believe this is a mandatory requirement. Worse, there is a potential implied requirements for some proxies to count the number of calls ingressed from/egressed to each gateway which is not ALWAYS practical. I would rather prefer a model where the gateway announces that it is in service (and optionally, its capacity) and then reports when it is out-of-resources or reaching its max capacity based on 2 thresholds dictated by the proxy. - in draft-roy-iptel-gw-server-discovery-00.txt, it is proposed to advertize the Entity Type. There was a very similar proposal some vendors to extend OSPv2+ with similar information and the consensus was that unless this information is very detailed (including registered protocol name(s), versions, profiles, ...), it is useless. There is also an implied requirement that by knowing this, some proxies may do some sort of capability negotiation. - draft-roy-iptel-itrp-00.txt: and why not TRIP or TRIP-gw? to me, this proposal does not stand as it could well be based on an existing protocol. Jean-Francois. > -----Original Message----- > From: iptel-admin@lists.bell-labs.com > [mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Jonathan > Rosenberg > Sent: Monday, October 01, 2001 10:48 AM > To: 'iptel@lists.bell-labs.com' > Subject: [IPTEL] the silence is deafening... > > > Folks, > > Its been about 3 weeks since our call for proposals for "gateway > registration" drafts ended. We actually have THREE proposals > on the table: > > http://search.ietf.org/internet-drafts/draft-roy-iptel-gw-serv > er-discovery-0 > 0.txt > http://search.ietf.org/internet-drafts/draft-roy-iptel-itrp-00.txt > > http://search.ietf.org/internet-drafts/draft-rs-trip-gw-02.txt > > http://search.ietf.org/internet-drafts/draft-zhao-iptel-gwloc- > slp-01.txt > > However, there has not been a single email post on this list > with comments > or questions. I'm not sure how to interpret that. Perhaps > people are just > busy (always true), or perhaps this is not important enough > for anyone to > take the time to focus on. However, if it is something that > people do not > feel is important enough to focus on, to the extent that they > are willing to > post comments or push their proposals, then I could only > conclude that it is > not something interesting enough to keep on the charter. I would be > perfectly happy to finish the MIB and close down the group; I > certainly have > plenty of other things to do. So, please do comment on these, > and make your > opinions known. If there is no discussion within another two > weeks, I will > consider this consensus to remove the item from the charter > and begin the > process to make that happen. > > -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 Tue Oct 2 10:20:25 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12976 for ; Tue, 2 Oct 2001 10:20:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6858444337; Tue, 2 Oct 2001 09:17:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by lists.bell-labs.com (Postfix) with ESMTP id E1F2C44336 for ; Tue, 2 Oct 2001 09:16:52 -0400 (EDT) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id KAA23492; Tue, 2 Oct 2001 10:20:14 -0400 (EDT) Message-ID: <3BB9CD1E.F091289F@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Francois Mule Cc: iptel@lists.bell-labs.com References: <000901c14afd$ae772630$d511a940@rwcjfmule01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] Entities and relationships 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 02 Oct 2001 10:20:14 -0400 Content-Transfer-Encoding: 7bit Jean-Francois Mule wrote: > > I will bark ;) I changed the subject to more closely reflect the topic at hand. I think part of the issue is that we seem to have somewhat divergent pictures of how deployment in a network might look like, and what kind of boxes provides what kind of information to whom. I suspect, once you strip away the labels, that each proposal can fit a variety of models, but that each proposal has a particular model in mind. I'm trying to paint a somewhat more differentiated picture than Fig. 1 in draft-rs-trip-gw-02. At the most fine-grained decomposition, we seem to have: === (UA) a SIP server that handles all calls for a set of (G) (G) a physical PSTN gateway, with DS-0s and kin coming out the back (L) announces gateway properties to other entities, not necessarily just Ls, but also other Ps, both within the same LAN, say, and further afield. (In my Internet2 example, it would announce nationwide, to maybe a hundred other sites.) Depending on the protocol and the architecture chosen ("push" or "pull", for example), (L) can be different entities; for example, in SLP, a SA or DA. ==== (P) a SIP proxy server that serves a whole domain, and presumably multiple G/UA combinations. It might also listen to (L) announcements. (P) is, in my view, optional, i.e., I should be able to run a system where I only have a UA+G. I believe that this architecture or decomposition is not arbitrary since it reflects the possible SIP (and, roughly, H.323) boxes that exist today. As usual, (UA) and its set of (G) can either be in the same box (no protocol between them) or they can be separated by an MGCP/Megaco/proprietary wire. As far as I can tell, each (G) in this model must "belong" to one UA, but I'm not sure on this point. (Clearly true for G+UA in one box, but MGCP/Megaco/proprietary cases are less clear to me.) More interestingly, (L) could be located on (P), (UA) or (G), depending on who knows what. With aggregation, you could even have combinations in the same IAD, as in "L on G announces to local L*, which has policy information and forwards to other L*'s further afield." In simple cases, it makes sense to have the UA+G+L all in one box, with all policy configuration and complete state knowledge. Imagine some sort of distributed gateway in DSL-equipped homes, with one phone line each, for example. I don't think there is a right or wrong architecture at this level, but each protocol should state which of these models it sees itself fitting into. Also, as Jean-Francois states, we need some clarity as to naming model: - prefixes ("I can dial 212, 908, 201 and have a total of N circuits") - trunks ("I have a trunk with 24 circuits") or whatever. I suspect that all protocols can be adjusted to fit these naming models, but it would be nice if we could agree on the model. Henning -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Oct 2 10:28:23 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13325 for ; Tue, 2 Oct 2001 10:28:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0955B44340; Tue, 2 Oct 2001 09:25:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by lists.bell-labs.com (Postfix) with ESMTP id 2284F44337 for ; Tue, 2 Oct 2001 09:24:26 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f92ERaC07826; Tue, 2 Oct 2001 10:27:36 -0400 (EDT) Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id KAA13271; Tue, 2 Oct 2001 10:26:14 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Oct 2001 10:27:35 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: Jean-Francois Mule , "'Jonathan Rosenberg'" , iptel@lists.bell-labs.com Subject: RE: [IPTEL] the silence is deafening... MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 2 Oct 2001 10:27:25 -0400 My response provided below [RRR]: -----Original Message----- From: Jean-Francois Mule [mailto:jfmule@clarent.com] I will bark ;) - in draft-roy-iptel-gw-server-discovery-00.txt, it is proposed to advertize the Entity Type. There was a very similar proposal some vendors to extend OSPv2+ with similar information and the consensus was that unless this information is very detailed (including registered protocol name(s), versions, profiles, ...), it is useless. There is also an implied requirement that by knowing this, some proxies may do some sort of capability negotiation. [RRR] GWs and servers are different entities. So, the entity type is coming from this perspective. If people want to differentiate among the GWs like telephony GWs, SIP-H.323 GWs, it is also possible. We can see why version, protocol name, etc. are not needed. These have NOT been proposed for capability negotiations. Definitely, we can discuss these items, if there are some concerns. The capability negotiation has been proposed whether send-only, receive-only, or send-receive-mode (like TRIP-GW), not for others that you have indicated. - draft-roy-iptel-itrp-00.txt: and why not TRIP or TRIP-gw? to me, this proposal does not stand as it could well be based on an existing protocol. [RRR] TRIP-GW does not have the discovery mechanisms. Another protocol is needed to do this. In addition, the base TRIP-GW protocol uses TCP as the transport and flooding (or limited broadcast) for sending information among the servers. Both UDP and TCP can be used in ITRP. Efficient multicasting can be used in ITRP. TRIP-GW's message structure are relatively complex and has not been proposed to deal with email IDs, URL IDs, etc, other than telephony GWs. Jean-Francois. > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Oct 2 10:30:23 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13473 for ; Tue, 2 Oct 2001 10:30:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 913164435D; Tue, 2 Oct 2001 09:27:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by lists.bell-labs.com (Postfix) with ESMTP id 3CEBE4435D for ; Tue, 2 Oct 2001 09:26:08 -0400 (EDT) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id KAA24719; Tue, 2 Oct 2001 10:29:29 -0400 (EDT) Message-ID: <3BB9CF48.E83CA03B@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Francois Mule Cc: "'Jonathan Rosenberg'" , iptel@lists.bell-labs.com, Weibin Zhao Subject: Re: [IPTEL] the silence is deafening... References: <000901c14afd$ae772630$d511a940@rwcjfmule01> Content-Type: text/plain; charset=us-ascii 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 02 Oct 2001 10:29:28 -0400 Content-Transfer-Encoding: 7bit Jean-Francois Mule wrote: > > - in draft-zhao-iptel-gwloc-slp-01.txt, it is proposed that "the > location server needs to know the capacity of each gateway." in > draft-rs-trip-gw-02.txt, i see a slightly different requirement in REQ4. > While some vendors would probably like to know the total gateway > capacity or how many ds0s are being managed in a network (for licensing > for e.g.), I do not believe this is a mandatory requirement. Worse, > there is a potential implied requirements for some proxies to count the > number of calls ingressed from/egressed to each gateway which is not > ALWAYS practical. I would rather prefer a model where the gateway > announces that it is in service (and optionally, its capacity) and then > reports when it is out-of-resources or reaching its max capacity based > on 2 thresholds dictated by the proxy. Yes, any parameter should be optional; we'll clarify. I also agree that both total capacity and current remaining capacity (or, inversely, circuits already tied up) are needed. As I said in my other message, I don't see the need for a SIP proxy in all cases, so I'm a little confused by your statement in the second half of the paragraph. > > - in draft-roy-iptel-gw-server-discovery-00.txt, it is proposed to > advertize the Entity Type. There was a very similar proposal some > vendors to extend OSPv2+ with similar information and the consensus was > that unless this information is very detailed (including registered > protocol name(s), versions, profiles, ...), it is useless. There is > also an implied requirement that by knowing this, some proxies may do > some sort of capability negotiation. > Plus, you're now re-inventing SLP one step at a time. If you want to advertise properties for general servers, I would like to know why this shouldn't be used for, say, printers or other network services. (This is not meant as a rhetorical question.) What makes a SIP-H.323 translator different from other complex network services? VoIP has a tendency, I think, to only look at their narrow niche, without considering whether a particular problem is shared across domains. If we have new problems that can't be solved by existing protocols, we should check whether our solution is generalizable at modest cost and thus serve a broader audience. This avoids having to implement hundreds of protocols, given that most VoIP implementations will need to support all the existing Internet protocols for other services. This also ensures that other people look at this and say "we looked at this when we designed and found it didn't work", just like Jean-Francois inference above. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Oct 2 10:47:24 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14589 for ; Tue, 2 Oct 2001 10:47:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 66F5244361; Tue, 2 Oct 2001 09:44:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by lists.bell-labs.com (Postfix) with ESMTP id 4F5C84435B for ; Tue, 2 Oct 2001 09:43:44 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f92El6C19569; Tue, 2 Oct 2001 10:47:06 -0400 (EDT) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id KAA25855; Tue, 2 Oct 2001 10:45:45 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Oct 2001 10:47:06 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: "Henning G. Schulzrinne" Cc: "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] the silence is deafening... MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 2 Oct 2001 10:17:59 -0400 My response sated below [RRR]: -----Original Message----- From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] "Roy, Radhika R, ALCTA" wrote: > > Per Henning's suggestions, I am adding the following . . . > > The common properties that all intra-ITAD (intra-domain) proposals need to > have: > > 1. A single protocol I don't understand this requirement. [RRR] For example, there are GWs and servers. The communications scenarios are GW <-> Server and Server <-> Server. In all scenarios, it is better to use the same protocol. > > 2. Gateways can be Telephony (e.g., E.164) GWs and/or SIP-H.323 GWs (E.164, > Email IDs, URL IDs) > > 3. Communication environments for address resolutions: a. GWs <-> > (Location/Route) Server and b. (Location/Route) Server <-> (Location/Route) > Server This depends on a particular model of the world; I don't think that's a given. [RRR] A large network will consist of many GWs and servers. Therefore, it is reasonable to have this kind of scenarios. Otherwise, it may be difficult to manage the large network. For example, if there are many-to-many communications relationship with every GW is communicating with every server, it will complicate the process in managing the network. More over, the needs for communications among the servers are not the same as of communications among the GWs and server. > > 4. Functionalities of the protocol needed: Discovery, Registration, > Confirmation (and Selective Updates of addresses, and Keep-Alive messages, > and Error-Notifications for efficiency reason). > > 5. Scalability of the protocol (e.g., Multicasting using connectionless > transport [e.g., UDP]) > > 6. Possible Extensions for Value-added features (e.g., capability > negotiations, alternate peers for back-up, capacity, policy, QOS) Just like for routing, depending on the complexity trade-offs, that may not be the right one. There is a reason, after all, that not everyone is running OSPF when router discovery is all you need. [RRR] These are value-added features and will definitely increase the complexity. However, the protocol may need to be flexible enough to accommodate these if needed. For example, reliability is an important one to have the back-up functional element. Therefore, a flexible protocol is always useful. > > C. GW-SLP (W. Zhao, et al) > > 1. The GW-SLP proposal extends the SLP protocol for discovery and > registration, but there exists a many-to-many relationship between the > gateways and servers. This may pose problems in managing the large networks. I don't see the problem. SLP commonly deals with many clients that need resource information and with many services. [RRR] The efficient communication scenarios are, as stated above, GW <-> Sever, and Sever <-> Server. So, the many-to-one and one-to-many seem to be better as opposed to many-to-many scenarios. It may be noted that discovery and registration are not the only requirements. The selective updates, keep-alive, etc. are also needed. > In ITRP proposal, it can be restricted such that a set of GWs can be > communicating only with a single server. > > 2. The GW-SLP proposal does not specify communications among the servers > and, GWs are required to communicate with all servers using multicasting if > multiple servers are deployed. That is, a new protocol may be needed if the > server-to-server communications are required. (Both ITRP and GW-TRIP provide > mechanisms for server to server communications.) That is bogus. DAs can communicate with each other, if that's the architecture selected. [RRR] Are you suggesting DAs will be using to perform selective updates, keep-alive and others extending the SLP protocol? If SLP can be extended to use in the communications scenarios GW <-> Server and Server <-> Server and all requirements are met, it will serve one good purpose - that is, one single protocol can be used for the intra-ITAD. Can we see the proposal that meet all requirements? > > 3. No mechanism is defined in the GW-SLP proposal if selective updates are > needed because it is not efficient to send the register message again and > again for simple updates. I don't know what you mean by selective updates. You mean for individual prefixes? SLP has partial updates, if really needed. (Based on experience, it seems to be deprecated and little used in practice.) Supported or not, my suspicion is that the complexity is not worth it, given the issues of synchronization of new "listeners". In general, at least in SIP (and RSVP, for another example), we have made the choice of providing complete state information, rather than incremental state. How large do you anticipate advertisements to be? Inside a network, is the bandwidth efficiency an issue? [RRR] The selective updates are very efficient. For example, many GWs will be communicating to a single server. A GW may deal with 100s, 1000s of addresses. If all GWs send their only the updated addresses, a sever only needs to send only those updated addresses to all other servers. In this way, there is an efficiency in communications. > > 4. A server may also need to aggregate the address information and may > require to send the same to all other servers and, there is a need for > communication among the servers (as suggested in ITRP and TRIP-GW). In > GW-SLP proposal, no protocol has been suggested for the server-to-server > communications. Bogus. See above. You can do whatever aggregation you want, if that's necessary. Clearly, the aggregated version has to be distinguished (it's a different "service"), but I don't see the protocol problem. [RRR] It is about server to server communication part. A server will aggregate and the same needs to sent to all other servers. Now, SLP proposal needs to clarify how it will do this part. Are you suggesting that DAs will do this meeting all requirements? Can the communications scenarios be limited to many-to-one (e.g., GW <-> Server) and one-to-many (e.g., server <-> Server) as appropriate? Will it also be possible to discover the GW(s) by a server, should a server need to do so to serve a call in certain circumstances? > > The above note provides a brief summary of all proposals. > > Comments will be appreciated. [RRR] Will we be able to accommodate all requirements extending the SLP protocol? -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Oct 2 10:50:23 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14794 for ; Tue, 2 Oct 2001 10:50:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7F72144367; Tue, 2 Oct 2001 09:47:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by lists.bell-labs.com (Postfix) with ESMTP id 356B94435D for ; Tue, 2 Oct 2001 09:46:36 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f92EnGC20705; Tue, 2 Oct 2001 10:49:16 -0400 (EDT) Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id KAA26874; Tue, 2 Oct 2001 10:47:55 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Oct 2001 10:49:15 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: "Henning G. Schulzrinne" , Jean-Francois Mule Cc: "'Jonathan Rosenberg'" , iptel@lists.bell-labs.com, Weibin Zhao Subject: RE: [IPTEL] the silence is deafening... MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 2 Oct 2001 10:48:56 -0400 My responses provided below [RRR]: -----Original Message----- From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Tuesday, October 02, 2001 10:29 AM > > - in draft-roy-iptel-gw-server-discovery-00.txt, it is proposed to > advertize the Entity Type. There was a very similar proposal some > vendors to extend OSPv2+ with similar information and the consensus was > that unless this information is very detailed (including registered > protocol name(s), versions, profiles, ...), it is useless. There is > also an implied requirement that by knowing this, some proxies may do > some sort of capability negotiation. > Plus, you're now re-inventing SLP one step at a time. If you want to advertise properties for general servers, I would like to know why this shouldn't be used for, say, printers or other network services. (This is not meant as a rhetorical question.) What makes a SIP-H.323 translator different from other complex network services? [RRR] Yes, SLP is an excellent protocol for discovery and registration. The above proposal is similar to SLP from discovery point of view, but has additional features. The mechanisms like discovery, registration, selective updates, keep-alive, confirmation, and error notifications have created a complete protocol (termed as ITRP) to meet the requirements (e.g., many-to-one, one-to-many, reliability, etc.). You are right that it is better if we could use the existing one to meet our purpose. We are just in the middle of this important discussion. You have already has sent another mail outlining the communications model. We will start from there. What makes a SIP-H.323 translator different from other complex network services? [RRR] For SLP, it does not matter. (For, TRIP-GW proposal, it needs to accommodate SIP-H.323 GW addresses.) ITRP also accommodates SIP-H.323 GW addresses. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ 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 Tue Oct 2 10:55:25 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15115 for ; Tue, 2 Oct 2001 10:55:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 10FC444376; Tue, 2 Oct 2001 09:52:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by lists.bell-labs.com (Postfix) with ESMTP id BBD4D44375 for ; Tue, 2 Oct 2001 09:51:27 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f92Esek12070; Tue, 2 Oct 2001 10:54:41 -0400 (EDT) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id KAA00004; Tue, 2 Oct 2001 10:53:18 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Oct 2001 10:54:39 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: "Anderson, Darby" , "Henning G. Schulzrinne" , Jonathan Rosenberg Cc: "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] the silence is deafening... MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 2 Oct 2001 10:19:05 -0400 -----Original Message----- From: Anderson, Darby [mailto:Darby.Anderson@integratelecom.com] I suppose my only concerns as of present are: 1. Would this twist still be TRIP? [RRR] No, it is not TRIP although the message formats will be similar to TRIP. 2. If so, would this add much more developement time for the devlopement of this protocol? [RRR] Any protocol that will be used for intra-domain communications will have some new features. 3. In reguards to Section A, Subsection 5, does this make provisions for redundancy/diversity of all network elements? (I.E. G/W's,LocServ,RouteServ,Etc.) [RRR] If one likes to provision the GW or server to improve reliability, the protocol will have the provision like this. -----Original Message----- From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] Sent: Monday, October 01, 2001 3:36 PM To: Henning G. Schulzrinne; Jonathan Rosenberg Cc: 'iptel@lists.bell-labs.com' Subject: RE: [IPTEL] the silence is deafening... Per Henning's suggestions, I am adding the following . . . The common properties that all intra-ITAD (intra-domain) proposals need to have: 1. A single protocol 2. Gateways can be Telephony (e.g., E.164) GWs and/or SIP-H.323 GWs (E.164, Email IDs, URL IDs) 3. Communication environments for address resolutions: a. GWs <-> (Location/Route) Server and b. (Location/Route) Server <-> (Location/Route) Server 4. Functionalities of the protocol needed: Discovery, Registration, Confirmation (and Selective Updates of addresses, and Keep-Alive messages, and Error-Notifications for efficiency reason). 5. Scalability of the protocol (e.g., Multicasting using connectionless transport [e.g., UDP]) 6. Possible Extensions for Value-added features (e.g., capability negotiations, alternate peers for back-up, capacity, policy, QOS) In short, the alternate proposals that we have can be described as follows: A. ITRP (R. Roy) 1. The proposed ITRP protocol satisfies the above properties. ITRP has also the properties what TRIP-GW or GW-SLP proposal also does. Briefly, it appears that both TRIP-GW and GW-SLP proposal may require more than one protocol to satisfy the needs while a single ITRP protocol will be able to do the same. 2. It has the capability for Discovery, Registration, Confirmation, Selective Updates of addresses, Keep-Alive messages, and Error-Notifications. The communication can be: a. GWs <-> (Location/Route) Server and b. (Location/Route) Server <-> (Location/Route) Server. 3. It has the ability to restrict the communications among the gateways and servers as needed: a. Many-to-One, b. One-to-Many, (and c. Many-to-Many). 4. Both UDP and TCP transport can be used as needed. Unlike TRIP-GW, it can use multicasting using for updates among the servers. 5. A server will also be able to aggregate the address information for scalability and efficiency and may be able to send the same to all other servers. 6. Value-added features like capability negotiations, alternate peers for back-up, capacity, etc. can be used. 7. The address resolutions can be provided for Telephony (e.g., E.164) GWs and/or SIP-H.323 GWs (E.164, Email IDs, URL IDs). 8. The proposed message formats of ITRP are similar to those of TRIP. B. TRIP-GW (J. Rosenberg, et al) 1. The TRIP-GW proposal needs another protocol for discovery of the gateways. Moreover, connectionless transport (e.g., UDP) is efficient for discovery protocols between the gateways and the servers (but it uses connection-oriented TCP protocol). 2. For servers to server communications, this protocol uses connection-oriented TCP transport protocol. When selective updates are made by the gateways to the any server, the said server uses flooding (or limited broadcast) to update that information among all other servers, instead of using more efficient multicasting (over the UDP transport for example). 3. TRIP-GW message sets are inherently complex because it has been designed to solve more complex problems like route aggregation and route propagation, which are not needed for the intra-ITAD communications. 4. In addition to Telephony numbers, we need to provide address resolutions for Email Ids, URL Ids, etc. as well. These items are yet to address by the TRIP-GW. C. GW-SLP (W. Zhao, et al) 1. The GW-SLP proposal extends the SLP protocol for discovery and registration, but there exists a many-to-many relationship between the gateways and servers. This may pose problems in managing the large networks. In ITRP proposal, it can be restricted such that a set of GWs can be communicating only with a single server. 2. The GW-SLP proposal does not specify communications among the servers and, GWs are required to communicate with all servers using multicasting if multiple servers are deployed. That is, a new protocol may be needed if the server-to-server communications are required. (Both ITRP and GW-TRIP provide mechanisms for server to server communications.) 3. No mechanism is defined in the GW-SLP proposal if selective updates are needed because it is not efficient to send the register message again and again for simple updates. 4. A server may also need to aggregate the address information and may require to send the same to all other servers and, there is a need for communication among the servers (as suggested in ITRP and TRIP-GW). In GW-SLP proposal, no protocol has been suggested for the server-to-server communications. The above note provides a brief summary of all proposals. Comments will be appreciated. Best regards, Radhika R. Roy rrroy@att.com -----Original Message----- From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Monday, October 01, 2001 2:39 PM To: Jonathan Rosenberg Cc: 'iptel@lists.bell-labs.com' Subject: Re: [IPTEL] the silence is deafening... I'll bite :-) One question is whether we need one solution or whether different solutions have different applications and trade-offs. After all, we have RIPv2, OSPF, IS-IS and some vendor-proprietary protocols (as well as simpler router discovery and advertisement via ICMP, IGMP and DHCP) as interior/intra-domain routing protocols and BGPv4 as exterior/inter-domain. Also, as with routing protocols, availability of broadcast/multicast plays a role here. I would like to be able to optimize efficiency (or reduce complexity) if multicast is available. As one real-life example I happen to be familiar with, Internet2 is multicast-enabled and is looking at how to distribute gateway information in the future. Also, the complexity of standardizing these things differ. In some cases, it's a new protocol, in others a profile, in the third mainly a new data structure (template). It might be helpful if the proponents/authors of each proposal could abstract their proposal into a common set of properties, of which I suggested a few above. (I'm sure there are many others I missed.) This will tell us if the proposals are different mainly because they make different assumptions on infrastructure and usage, and thus likely will be complementary, or whether they are solving the same problem in the same space. From what I can tell, the number of parameters for each gateway appears to be fairly small, so that translation between the schemes or to an exterior scheme is reasonably simple. It is also not clear to me that just blindly "exporting" the information wholesale to an inter-domain scheme is desirable. If you consider the Internet2 example above, while universities might make their facilities available in a "peering"/mutual-aid fashion (no pay) to other universities, they may have much more restrictive policies as to who gets to see what once it leaves Internet2. Jonathan Rosenberg wrote: > > Folks, > > Its been about 3 weeks since our call for proposals for "gateway > registration" drafts ended. We actually have THREE proposals on the table: > > http://search.ietf.org/internet-drafts/draft-roy-iptel-gw-server-discovery-0 > 0.txt > http://search.ietf.org/internet-drafts/draft-roy-iptel-itrp-00.txt > > http://search.ietf.org/internet-drafts/draft-rs-trip-gw-02.txt > > http://search.ietf.org/internet-drafts/draft-zhao-iptel-gwloc-slp-01.txt > > However, there has not been a single email post on this list with comments > or questions. I'm not sure how to interpret that. Perhaps people are just > busy (always true), or perhaps this is not important enough for anyone to > take the time to focus on. However, if it is something that people do not > feel is important enough to focus on, to the extent that they are willing to > post comments or push their proposals, then I could only conclude that it is > not something interesting enough to keep on the charter. I would be > perfectly happy to finish the MIB and close down the group; I certainly have > plenty of other things to do. So, please do comment on these, and make your > opinions known. If there is no discussion within another two weeks, I will > consider this consensus to remove the item from the charter and begin the > process to make that happen. > -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ 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 Tue Oct 2 11:07:23 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15611 for ; Tue, 2 Oct 2001 11:07:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 066924435C; Tue, 2 Oct 2001 10:04:01 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by lists.bell-labs.com (Postfix) with ESMTP id 8DC5544340 for ; Tue, 2 Oct 2001 10:03:07 -0400 (EDT) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id LAA26840; Tue, 2 Oct 2001 11:06:27 -0400 (EDT) Message-ID: <3BB9D7F3.1DD53C22@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: "Roy, Radhika R, ALCTA" Cc: "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] the silence is deafening... References: Content-Type: text/plain; charset=us-ascii 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 02 Oct 2001 11:06:27 -0400 Content-Transfer-Encoding: 7bit "Roy, Radhika R, ALCTA" wrote: > > > [RRR] For example, there are GWs and servers. The communications scenarios > are GW <-> Server and Server <-> Server. In all scenarios, it is better to > use the same protocol. Since you don't say what you mean by "server", I can't understand this requirement. See my last note on architecture. Also, just stating "it is better" is not particularly helpful. > [RRR] A large network will consist of many GWs and servers. Therefore, it is > reasonable to have this kind of scenarios. Otherwise, it may be difficult to > manage the large network. For example, if there are many-to-many > communications relationship with every GW is communicating with every > server, it will complicate the process in managing the network. More over, > the needs for communications among the servers are not the same as of > communications among the GWs and server. Again, you state your assumptions as facts. This is not very helpful. > [RRR] These are value-added features and will definitely increase the > complexity. However, the protocol may need to be flexible enough to > accommodate these if needed. For example, reliability is an important one to > have the back-up functional element. Therefore, a flexible protocol is > always useful. > We all agree, in the abstract, that reliability and flexibility are good, but I don't understand how this applies here. Just as a "for instance", SLP supports redundancy for SAs, DAs and UAs, in various meanings of the word redundancy. I'd be surprised if TRIPlite couldn't do something similar. > > [RRR] The efficient communication scenarios are, as stated above, GW <-> > Sever, and Sever <-> Server. So, the many-to-one and one-to-many seem to be > better as opposed to many-to-many scenarios. It may be noted that discovery > and registration are not the only requirements. The selective updates, > keep-alive, etc. are also needed. Again, you state your assumptions as facts. Selective updates (by which I assume you mean partial updates of some properties of a gateway) is only useful if the volume of per-entity information is so high that a complete update is not feasible. Absent of that, partial updates are not desirable. I have no idea why you believe that SLP doesn't support many-to-one or one-to-many scenarios. As I said before, SLP supports partial updates, if you really want them. (I don't see the need in this case, but maybe you can show why each update has tens of kilobytes of information.) > > [RRR] Are you suggesting DAs will be using to perform selective updates, > keep-alive and others extending the SLP protocol? I realize that this is a different WG, but we have been working with the SLP WG on DA replication for about (I'm guessing) a year. This requires only very modest changes to SLP DAs, and none to SAs or UAs. See http://www.ietf.org/internet-drafts/draft-zhao-slp-da-interaction-10.txt > [RRR] The selective updates are very efficient. For example, many GWs will > be communicating to a single server. A GW may deal with 100s, 1000s of > addresses. If all GWs send their only the updated addresses, a sever only > needs to send only those updated addresses to all other servers. In this > way, there is an efficiency in communications. I'm sorry, I just don't see how a gateway advertises 1000s of addresses one at a time. Are you going to advertise each area code in the world separately? Just like in TRIP, I would imagine that you do longest-prefix-matching if you need to carve out special cases. Realistically, I see gateways advertising the list of (maybe 30?) 7-digit prefixes (1212854, etc.) that are within local calling range, maybe some regional calls and then a few dozen different international groups, based on price similarity. But this assumes that the advertisement includes cost; otherwise, the number of prefixes is much, much smaller as they all look the same. We seem to have very different views of how gateways work. Can you explain your view? > [RRR] It is about server to server communication part. A server will Since you don't explain what you mean by "server" and we got tons of different ones (UAS, proxy, various gateway location protocol servers, depending on the specifics of the protocol, with at least two different kinds in SLP), this is hard to discuss. > > [RRR] Will we be able to accommodate all requirements extending the SLP > protocol? Once the architecture(s) and requirements are clear, we can make progress towards answering this, not just for SLP. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Oct 2 11:38:25 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17047 for ; Tue, 2 Oct 2001 11:38:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D33DF44337; Tue, 2 Oct 2001 10:35:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from integraonline.com (inet-1a-bvtn.integraonline.com [206.163.82.156]) by lists.bell-labs.com (Postfix) with SMTP id C8D3744336 for ; Tue, 2 Oct 2001 10:34:35 -0400 (EDT) Received: (qmail 3741 invoked from network); 2 Oct 2001 15:38:01 -0000 Received: from fw-1-bvtn.integratelecom.com (HELO beaexch2.ads.integratelecom.com) ([206.163.82.5]) (envelope-sender ) by inet-1b-bvtn.integraonline.com (qmail-ldap-1.03) with SMTP for ; 2 Oct 2001 15:38:01 -0000 Received: by beaexch2.ads.integratelecom.com with Internet Mail Service (5.5.2650.21) id ; Tue, 2 Oct 2001 08:37:57 -0700 Message-ID: From: "Anderson, Darby" To: "'Henning G. Schulzrinne'" , iptel@lists.bell-labs.com Cc: Weibin Zhao Subject: RE: [IPTEL] Parameters for gateway advertisements MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 2 Oct 2001 08:37:56 -0700 IMHO, I would beleive that ASR Would be a good thing, however Im not for sure how useful a PDD index at a voice gateway would be, as there are other factors that could induce further delay into the start of a voice call? -----Original Message----- From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Monday, October 01, 2001 5:19 PM To: iptel@lists.bell-labs.com Cc: Weibin Zhao Subject: [IPTEL] Parameters for gateway advertisements Beyond some notion of cost and maybe load or first-derivative of load, are there other (optional) parameters that that are of interest for gateways? One parameter commonly used to advertise international trunks is "answer seizure ratio" (ASR), which apparently provides some indication as to the loading of the system on the other side. Is this useful? Some other QOS measure such as (post-dial delay) PDD? -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ 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 Tue Oct 2 12:06:23 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18670 for ; Tue, 2 Oct 2001 12:06:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1914D44340; Tue, 2 Oct 2001 11:03:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 33F0444340 for ; Tue, 2 Oct 2001 11:02:29 -0400 (EDT) Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA10960; Tue, 2 Oct 2001 12:05:50 -0400 (EDT) From: Weibin Zhao X-X-Sender: To: "Henning G. Schulzrinne" Cc: "'iptel@lists.bell-labs.com'" In-Reply-To: <3BB9D7F3.1DD53C22@cs.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [IPTEL] Use SLP for iptel-gwloc 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 2 Oct 2001 12:05:50 -0400 (EDT) On Tue, 2 Oct 2001, Henning G. Schulzrinne wrote: > I realize that this is a different WG, but we have been working with the > SLP WG on DA replication for about (I'm guessing) a year. This requires > only very modest changes to SLP DAs, and none to SAs or UAs. See > http://www.ietf.org/internet-drafts/draft-zhao-slp-da-interaction-10.txt Hello all, I have been working with Prof. Henning on SLP DA (Directory Agent) replication and other SLP enhancements. The current version of slp-da-interaction is 12, so the link should be: http://www.ietf.org/internet-drafts/draft-zhao-slp-da-interaction-12.txt. This draft enhances SLP with a lightweight DA-to-DA (server-to-server) protocol for propagating service registration information. To use SLP for iptel-gwloc, we need to define a service template for iptel gateway: a set of attributes. These attributes can be defined as required or as optional. Now we are working on a new version of the template specification. A sample of the template is as follows: ----------------------template begins here----------------------- template-type = iptel-gw template-version = 1.0 template-description = The 'service:iptel-gw:' template describes the attributes supported by the Internet telephony gateway service. template-url-syntax = # service:iptel-gw://: total-capacity = integer # Total number of phone calls that can be supported by the gateway remaining-capacity = integer # Number of phone calls that can be further supported by the gateway prefix-list = string M L # A list of phone number prefixes that can be reached from the # gateway. Each phone number prefix MUST be an E.164 number prefix # without visual separators and without the "+" prefix. # # Grammar: # prefix-list = prefix / prefix ',' prefix-list # prefix = 1*DIGIT # DIGIT = %x30-39 # # Example: # prefix-list = 1212,8610,4930 # # where 1212 --- New York, NY, USA # 8610 --- Beijing, P.R.China # 4930 --- Berlin, Germany cost-list = string M L # A list of costs for reaching each phone number prefix defined in # the "prefix-list" attribute. The last element of this list may # use '*' to represent all unspecified prefixes. The cost is given # in a relative manner, no unit of cost is needed. # # Grammar: # cost-list = cost-info / cost-info ',' cost-list # cost-info = prefixes ':' cost # prefixes = prefix / '*' # prefix = 1*DIGIT # cost = 1*DIGIT # DIGIT = %x30-39 # # In this "cost-list" attribute, prefix A MUST preceed prefix B if # A is more specific than B, e.g., 1212 MUST preceed 1. # To determine the cost for reaching a prefix, use the longest # matching for prefix. # # Example: # cost-list = 1212:5,1:10,*:20 # # where the costs are as follows: # Prefix Unit of Cost # 1212 (New York, NY, USA) 5 # 1 (all other places in USA/Canada) 10 # * (the rest of world except USA/Canada) 20 -----------------------template ends here------------------------ One important issue is: what attributes are needed for whole gateway (such as total-capacity, remaining-capacity), and what attributes are needed for each phone number prefix (such as cost, ASR). Comments are welcome, thanks. -Weibin _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Oct 2 12:30:23 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19377 for ; Tue, 2 Oct 2001 12:30:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BC79644362; Tue, 2 Oct 2001 11:27:01 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mail.net2phone.com (mail.net2phone.com [216.53.3.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9367144336 for ; Tue, 2 Oct 2001 11:26:11 -0400 (EDT) Received: from mailsvr.net2phone.com (exchange.net2phone.com [216.53.60.1]) by mail.net2phone.com (8.11.5/8.11.5) with ESMTP id f92GTGP06901; Tue, 2 Oct 2001 12:29:16 -0400 (EDT) Received: by mailsvr with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Oct 2001 12:29:28 -0400 Message-ID: <6F46FABB90ABD411BD690002B3152FB96BF45E@lkwmail01> From: Jeffrey Skelton To: "'Anderson, Darby'" , "'Henning G. Schulzrinne'" , iptel@lists.bell-labs.com Cc: Weibin Zhao Subject: RE: [IPTEL] Parameters for gateway advertisements MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 2 Oct 2001 12:26:59 -0400 By "of interest for gateways" do you mean as a gateway or trunk characteristic that is measurable at a gateway? ASR and PDD would be good and can likely be measured and dynamically updated at the gateway. Another characteristic is something like a more subjective mean opinion score for call quality on a particular trunk. This is interesting but is probably not likely to be measured and dynamically updated for advertisement at the gateway. -----Original Message----- From: Anderson, Darby [mailto:Darby.Anderson@integratelecom.com] Sent: Tuesday, October 02, 2001 11:38 AM To: 'Henning G. Schulzrinne'; iptel@lists.bell-labs.com Cc: Weibin Zhao Subject: RE: [IPTEL] Parameters for gateway advertisements IMHO, I would beleive that ASR Would be a good thing, however Im not for sure how useful a PDD index at a voice gateway would be, as there are other factors that could induce further delay into the start of a voice call? -----Original Message----- From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Monday, October 01, 2001 5:19 PM To: iptel@lists.bell-labs.com Cc: Weibin Zhao Subject: [IPTEL] Parameters for gateway advertisements Beyond some notion of cost and maybe load or first-derivative of load, are there other (optional) parameters that that are of interest for gateways? One parameter commonly used to advertise international trunks is "answer seizure ratio" (ASR), which apparently provides some indication as to the loading of the system on the other side. Is this useful? Some other QOS measure such as (post-dial delay) PDD? -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ 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 Tue Oct 2 12:32:23 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19442 for ; Tue, 2 Oct 2001 12:32:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D948844374; Tue, 2 Oct 2001 11:29:01 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 95DA244336 for ; Tue, 2 Oct 2001 11:28:09 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f92GVV326956; Tue, 2 Oct 2001 12:31:31 -0400 (EDT) Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id MAA13732; Tue, 2 Oct 2001 12:30:06 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Oct 2001 12:31:27 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: "Henning G. Schulzrinne" Cc: "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] the silence is deafening... MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 2 Oct 2001 12:31:21 -0400 -----Original Message----- From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] "Roy, Radhika R, ALCTA" wrote: > > > [RRR] For example, there are GWs and servers. The communications scenarios > are GW <-> Server and Server <-> Server. In all scenarios, it is better to > use the same protocol. Since you don't say what you mean by "server", I can't understand this requirement. See my last note on architecture. Also, just stating "it is better" is not particularly helpful. [RRR] I will relate this in your earlier architectural note in a separate mail. [Servers can be LSs or PRs (or UAs). From your architectural point of view, for GW <-> server, L is located to GWs. In Server <-> Server, aggregation is done and L can be located to the Server. So, my point has been that the same protocol (may be the same L or L*) needs to be used.] > [RRR] A large network will consist of many GWs and servers. Therefore, it is > reasonable to have this kind of scenarios. Otherwise, it may be difficult to > manage the large network. For example, if there are many-to-many > communications relationship with every GW is communicating with every > server, it will complicate the process in managing the network. More over, > the needs for communications among the servers are not the same as of > communications among the GWs and server. Again, you state your assumptions as facts. This is not very helpful. [RRR] The above clarifications may answer this. > [RRR] These are value-added features and will definitely increase the > complexity. However, the protocol may need to be flexible enough to > accommodate these if needed. For example, reliability is an important one to > have the back-up functional element. Therefore, a flexible protocol is > always useful. > We all agree, in the abstract, that reliability and flexibility are good, but I don't understand how this applies here. Just as a "for instance", SLP supports redundancy for SAs, DAs and UAs, in various meanings of the word redundancy. I'd be surprised if TRIPlite couldn't do something similar. [RRR] Good. > > [RRR] The efficient communication scenarios are, as stated above, GW <-> > Sever, and Sever <-> Server. So, the many-to-one and one-to-many seem to be > better as opposed to many-to-many scenarios. It may be noted that discovery > and registration are not the only requirements. The selective updates, > keep-alive, etc. are also needed. Again, you state your assumptions as facts. Selective updates (by which I assume you mean partial updates of some properties of a gateway) is only useful if the volume of per-entity information is so high that a complete update is not feasible. Absent of that, partial updates are not desirable. [RRR] Yes, you are right in describing the definition of selective updates. The telephone numbers, email IDs, URL IDs, etc. are also considered together. So, there may be a good number of entries (and updates). I have no idea why you believe that SLP doesn't support many-to-one or one-to-many scenarios. [RRR] Good. The GW-SLP extension proposal assumes many-to-many scenarios. As I explained before, if we consider SA <-> DA and DA <-> DA model together where aggregation and selective updates are also considered. As I said before, SLP supports partial updates, if you really want them. (I don't see the need in this case, but maybe you can show why each update has tens of kilobytes of information.) [RRR] We cannot exclude this need right away because telephone numbers, email IDs, URL IDs, etc. will be considered together. > > [RRR] Are you suggesting DAs will be using to perform selective updates, > keep-alive and others extending the SLP protocol? I realize that this is a different WG, but we have been working with the SLP WG on DA replication for about (I'm guessing) a year. This requires only very modest changes to SLP DAs, and none to SAs or UAs. See http://www.ietf.org/internet-drafts/draft-zhao-slp-da-interaction-10.txt [RRR] Certainly, I will look into it. (It would have been better if this reference could be provided in the earlier GW-SLP draft.) > [RRR] The selective updates are very efficient. For example, many GWs will > be communicating to a single server. A GW may deal with 100s, 1000s of > addresses. If all GWs send their only the updated addresses, a sever only > needs to send only those updated addresses to all other servers. In this > way, there is an efficiency in communications. I'm sorry, I just don't see how a gateway advertises 1000s of addresses one at a time. Are you going to advertise each area code in the world separately? Just like in TRIP, I would imagine that you do longest-prefix-matching if you need to carve out special cases. Realistically, I see gateways advertising the list of (maybe 30?) 7-digit prefixes (1212854, etc.) that are within local calling range, maybe some regional calls and then a few dozen different international groups, based on price similarity. But this assumes that the advertisement includes cost; otherwise, the number of prefixes is much, much smaller as they all look the same. We seem to have very different views of how gateways work. Can you explain your view? [RRR] As mentioned above, telephone numbers, email IDs, URL IDs, etc. may also be considered together. > > [RRR] Will we be able to accommodate all requirements extending the SLP > protocol? Once the architecture(s) and requirements are clear, we can make progress towards answering this, not just for SLP. [RRR] Agreed. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Oct 2 12:53:27 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20250 for ; Tue, 2 Oct 2001 12:53:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9A29B44381; Tue, 2 Oct 2001 11:50:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from integraonline.com (web-2-bvtn.integraonline.com [206.163.82.91]) by lists.bell-labs.com (Postfix) with SMTP id ED1F744380 for ; Tue, 2 Oct 2001 11:49:04 -0400 (EDT) Received: (qmail 10729 invoked from network); 2 Oct 2001 16:52:31 -0000 Received: from fw-1-bvtn.integratelecom.com (HELO beaexch2.ads.integratelecom.com) ([206.163.82.5]) (envelope-sender ) by web-2-bvtn.integraonline.com (qmail-ldap-1.03) with SMTP for ; 2 Oct 2001 16:52:31 -0000 Received: by beaexch2.ads.integratelecom.com with Internet Mail Service (5.5.2650.21) id ; Tue, 2 Oct 2001 09:52:28 -0700 Message-ID: From: "Anderson, Darby" To: "'Jeffrey Skelton'" , "Anderson, Darby" , "'Henning G. Schulzrinne'" , iptel@lists.bell-labs.com Cc: Weibin Zhao Subject: RE: [IPTEL] Parameters for gateway advertisements MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 2 Oct 2001 09:52:26 -0700 Well... I was refering implicitly to end office trunking, since PDD will be pretty consistant, and thus working out to a linear PDD for the same amount of trunks at a particular G/W, going to a End Office, that was mainly the reason I felt as though it prolly wasnt that nessary, when trunking moves over to a tandem tho, is where a PDD scoreing schema could be of use (Different measureable amounts of PDD from one End Office to a Tandem, to another), but still this scoreing factor is a formula derived at the G/W, and #1 theres the possibility that each G/W vendor may have their own tweek on how they arrive at a number for that, and #2 other elements in the network have the possibility of slowing down the call processing further, beyond the claim of PDD score at the G/W Im not saying this shouldent be included, Im just wondering how relevant it is, if a majority of people are going to windup tying G/W's onto Tandem's, it prolly IS a good idea to use that, if using E/O Trunking, it may not be as nessary, seeing as though the whole serving area uses the same office parameters for that switch -----Original Message----- From: Jeffrey Skelton [mailto:jss@net2phone.com] Sent: Tuesday, October 02, 2001 10:27 AM To: 'Anderson, Darby'; 'Henning G. Schulzrinne'; iptel@lists.bell-labs.com Cc: Weibin Zhao Subject: RE: [IPTEL] Parameters for gateway advertisements By "of interest for gateways" do you mean as a gateway or trunk characteristic that is measurable at a gateway? ASR and PDD would be good and can likely be measured and dynamically updated at the gateway. Another characteristic is something like a more subjective mean opinion score for call quality on a particular trunk. This is interesting but is probably not likely to be measured and dynamically updated for advertisement at the gateway. -----Original Message----- From: Anderson, Darby [mailto:Darby.Anderson@integratelecom.com] Sent: Tuesday, October 02, 2001 11:38 AM To: 'Henning G. Schulzrinne'; iptel@lists.bell-labs.com Cc: Weibin Zhao Subject: RE: [IPTEL] Parameters for gateway advertisements IMHO, I would beleive that ASR Would be a good thing, however Im not for sure how useful a PDD index at a voice gateway would be, as there are other factors that could induce further delay into the start of a voice call? -----Original Message----- From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Monday, October 01, 2001 5:19 PM To: iptel@lists.bell-labs.com Cc: Weibin Zhao Subject: [IPTEL] Parameters for gateway advertisements Beyond some notion of cost and maybe load or first-derivative of load, are there other (optional) parameters that that are of interest for gateways? One parameter commonly used to advertise international trunks is "answer seizure ratio" (ASR), which apparently provides some indication as to the loading of the system on the other side. Is this useful? Some other QOS measure such as (post-dial delay) PDD? -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ 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 Tue Oct 2 12:57:36 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20618 for ; Tue, 2 Oct 2001 12:57:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A38FA44387; Tue, 2 Oct 2001 11:54:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169]) by lists.bell-labs.com (Postfix) with ESMTP id 726F444391 for ; Tue, 2 Oct 2001 11:53:27 -0400 (EDT) Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA22773; Tue, 2 Oct 2001 12:56:40 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-145.cisco.com [161.44.87.145]) by cia.cisco.com (Mirapoint) with ESMTP id ARN08001; Tue, 2 Oct 2001 12:56:44 -0400 (EDT) Message-Id: <4.3.2.7.2.20011002130003.00aff670@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Weibin Zhao From: Michael Hammer Subject: Re: [IPTEL] Use SLP for iptel-gwloc Cc: "Henning G. Schulzrinne" , "'iptel@lists.bell-labs.com'" In-Reply-To: References: <3BB9D7F3.1DD53C22@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/html; 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 02 Oct 2001 13:00:52 -0400 Small observation:  Are your units in U.S. dollars or Deutsch Marks or Euros?

Mike


At 12:05 PM 10/2/2001 -0400, Weibin Zhao wrote:


On Tue, 2 Oct 2001, Henning G. Schulzrinne wrote:

> I realize that this is a different WG, but we have been working with the
> SLP WG on DA replication for about (I'm guessing) a year. This requires
> only very modest changes to SLP DAs, and none to SAs or UAs. See
> http://www.ietf.org/internet-drafts/draft-zhao-slp-da-interaction-10.txt

Hello all,

I have been working with Prof. Henning on SLP DA (Directory Agent)
replication and other SLP enhancements. The current version of
slp-da-interaction is 12, so the link should be:
http://www.ietf.org/internet-drafts/draft-zhao-slp-da-interaction-12.txt.
This draft enhances SLP with a lightweight DA-to-DA (server-to-server)
protocol for propagating service registration information.

To use SLP for iptel-gwloc, we need to define a service template
for iptel gateway: a set of attributes. These attributes can be
defined as required or as optional. Now we are working on a new version
of the template specification. A sample of the template is as follows:

   ----------------------template begins here-----------------------

   template-type = iptel-gw

   template-version = 1.0

   template-description =
     The 'service:iptel-gw:' template describes the attributes
     supported by the Internet telephony gateway service.

   template-url-syntax =
   # service:iptel-gw://<hostname>:<port>

   total-capacity = integer
   # Total number of phone calls that can be supported by the gateway

   remaining-capacity = integer
   # Number of phone calls that can be further supported by the gateway

   prefix-list = string M L
   # A list of phone number prefixes that can be reached from the
   # gateway. Each phone number prefix MUST be an E.164 number prefix
   # without visual separators and without the "+" prefix.
   #
   # Grammar:
   #     prefix-list = prefix / prefix ',' prefix-list
   #     prefix      = 1*DIGIT
   #     DIGIT       = %x30-39
   #
   # Example:
   #     prefix-list = 1212,8610,4930
   #
   # where 1212 --- New York, NY, USA
   #       8610 --- Beijing, P.R.China
   #       4930 --- Berlin, Germany

   cost-list = string M L
   # A list of costs for reaching each phone number prefix defined in
   # the "prefix-list" attribute. The last element of this list may
   # use '*' to represent all unspecified prefixes. The cost is given
   # in a relative manner, no unit of cost is needed.
   #
   # Grammar:
   #     cost-list = cost-info / cost-info ',' cost-list
   #     cost-info = prefixes ':' cost
   #     prefixes  = prefix / '*'
   #     prefix    = 1*DIGIT
   #     cost      = 1*DIGIT
   #     DIGIT     = %x30-39
   #
   # In this "cost-list" attribute, prefix A MUST preceed prefix B if
   # A is more specific than B, e.g., 1212 MUST preceed 1.
   # To determine the cost for reaching a prefix, use the longest
   # matching for prefix.
   #
   # Example:
   #     cost-list = 1212:5,1:10,*:20
   #
   # where the costs are as follows:
   #               Prefix                              Unit of Cost
   #        1212 (New York, NY, USA)                         5
   #        1    (all other places in USA/Canada)           10
   #        *    (the rest of world except USA/Canada)      20

   -----------------------template ends here------------------------

One important issue is: what attributes are needed for whole gateway
(such as total-capacity, remaining-capacity), and what attributes are
needed for each phone number prefix (such as cost, ASR).

Comments are welcome, thanks.

-Weibin


_______________________________________________
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 Tue Oct 2 13:09:27 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21505 for ; Tue, 2 Oct 2001 13:09:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0BBF24438A; Tue, 2 Oct 2001 12:06:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by lists.bell-labs.com (Postfix) with ESMTP id 8939B44383 for ; Tue, 2 Oct 2001 12:05:17 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A48F853C03B8; Tue, 02 Oct 2001 13:08:31 -0400 Message-ID: <00a001c14b64$40a8c660$2300000a@acmepacket.com> From: "Bob Penfield" To: "Roy, Radhika R, ALCTA" , "Anderson, Darby" , "Henning G. Schulzrinne" , "Jonathan Rosenberg" Cc: References: Subject: Re: [IPTEL] the silence is deafening... MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 2 Oct 2001 13:04:07 -0400 Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Roy, Radhika R, ALCTA" To: "Anderson, Darby" ; "Henning G. Schulzrinne" ; "Jonathan Rosenberg" Cc: Sent: Tuesday, October 02, 2001 10:19 AM Subject: RE: [IPTEL] the silence is deafening... > > > -----Original Message----- > From: Anderson, Darby [mailto:Darby.Anderson@integratelecom.com] > > I suppose my only concerns as of present are: > > 1. Would this twist still be TRIP? > > [RRR] No, it is not TRIP although the message formats will be similar to > TRIP. You seem to be contradicting yourself. You want to use a single protocol, yet you claim TRIP is not appropriate. It seems to me that all of the routing information you are sharing with ITRP is nearly identical to that shared with TRIP, it just has a few extra atributes. Why can't we extend TRIP to support the additional attributes and the discovery mechanism needed. Or maybe use a separate discovery mechanism (maybe SLP). The SIP spec describes a way to find SIP servers that does not use SIP. Once the routing information goes over the wall from the ITRP or SLP side to the TRIP side, it (at least some of it) is going to flooded to all the TRIP speakers in the ITAD. This seems to go against REQ 9. I find SLP bit more appealing than ITRP, but I have trouble with the need for every gateway to communicate with every routing server in the ITAD. This may be OK if there are just a few. > > 2. If so, would this add much more developement time for the devlopement of > this protocol? > > [RRR] Any protocol that will be used for intra-domain communications will > have some new features. > I guess I have a problem with having to implement two different protocol to communicate virtually the same information. > 3. In reguards to Section A, Subsection 5, does this make provisions for > redundancy/diversity of all network elements? (I.E. > G/W's,LocServ,RouteServ,Etc.) > > [RRR] If one likes to provision the GW or server to improve reliability, the > protocol will have the provision like this. > > > -----Original Message----- > From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] > Sent: Monday, October 01, 2001 3:36 PM > To: Henning G. Schulzrinne; Jonathan Rosenberg > Cc: 'iptel@lists.bell-labs.com' > Subject: RE: [IPTEL] the silence is deafening... > > > Per Henning's suggestions, I am adding the following . . . > > The common properties that all intra-ITAD (intra-domain) proposals need to > have: > > 1. A single protocol > > 2. Gateways can be Telephony (e.g., E.164) GWs and/or SIP-H.323 GWs (E.164, > Email IDs, URL IDs) > > 3. Communication environments for address resolutions: a. GWs <-> > (Location/Route) Server and b. (Location/Route) Server <-> (Location/Route) > Server > > 4. Functionalities of the protocol needed: Discovery, Registration, > Confirmation (and Selective Updates of addresses, and Keep-Alive messages, > and Error-Notifications for efficiency reason). > > 5. Scalability of the protocol (e.g., Multicasting using connectionless > transport [e.g., UDP]) > > 6. Possible Extensions for Value-added features (e.g., capability > negotiations, alternate peers for back-up, capacity, policy, QOS) > > In short, the alternate proposals that we have can be described as follows: > > A. ITRP (R. Roy) > > 1. The proposed ITRP protocol satisfies the above properties. ITRP has also > the properties what TRIP-GW or GW-SLP proposal also does. Briefly, it > appears that both TRIP-GW and GW-SLP proposal may require more than one > protocol to satisfy the needs while a single ITRP protocol will be able to > do the same. > > 2. It has the capability for Discovery, Registration, Confirmation, > Selective Updates of addresses, Keep-Alive messages, and > Error-Notifications. The communication can be: a. GWs <-> (Location/Route) > Server and b. (Location/Route) Server <-> (Location/Route) Server. > > 3. It has the ability to restrict the communications among the gateways and > servers as needed: a. Many-to-One, b. One-to-Many, (and c. Many-to-Many). > > 4. Both UDP and TCP transport can be used as needed. Unlike TRIP-GW, it can > use multicasting using for updates among the servers. > > 5. A server will also be able to aggregate the address information for > scalability and efficiency and may be able to send the same to all other > servers. > > 6. Value-added features like capability negotiations, alternate peers for > back-up, capacity, etc. can be used. > > 7. The address resolutions can be provided for Telephony (e.g., E.164) GWs > and/or SIP-H.323 GWs (E.164, Email IDs, URL IDs). > > 8. The proposed message formats of ITRP are similar to those of TRIP. > > > B. TRIP-GW (J. Rosenberg, et al) > > 1. The TRIP-GW proposal needs another protocol for discovery of the > gateways. Moreover, connectionless transport (e.g., UDP) is efficient for > discovery protocols between the gateways and the servers (but it uses > connection-oriented TCP protocol). > > 2. For servers to server communications, this protocol uses > connection-oriented TCP transport protocol. When selective updates are made > by the gateways to the any server, the said server uses flooding (or limited > broadcast) to update that information among all other servers, instead of > using more efficient multicasting (over the UDP transport for example). > > 3. TRIP-GW message sets are inherently complex because it has been designed > to solve more complex problems like route aggregation and route propagation, > which are not needed for the intra-ITAD communications. > > 4. In addition to Telephony numbers, we need to provide address resolutions > for Email Ids, URL Ids, etc. as well. These items are yet to address by the > TRIP-GW. > > > C. GW-SLP (W. Zhao, et al) > > 1. The GW-SLP proposal extends the SLP protocol for discovery and > registration, but there exists a many-to-many relationship between the > gateways and servers. This may pose problems in managing the large networks. > In ITRP proposal, it can be restricted such that a set of GWs can be > communicating only with a single server. > > 2. The GW-SLP proposal does not specify communications among the servers > and, GWs are required to communicate with all servers using multicasting if > multiple servers are deployed. That is, a new protocol may be needed if the > server-to-server communications are required. (Both ITRP and GW-TRIP provide > mechanisms for server to server communications.) > > 3. No mechanism is defined in the GW-SLP proposal if selective updates are > needed because it is not efficient to send the register message again and > again for simple updates. > > 4. A server may also need to aggregate the address information and may > require to send the same to all other servers and, there is a need for > communication among the servers (as suggested in ITRP and TRIP-GW). In > GW-SLP proposal, no protocol has been suggested for the server-to-server > communications. > > The above note provides a brief summary of all proposals. > > Comments will be appreciated. > > Best regards, > > Radhika R. Roy > rrroy@att.com > > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, October 01, 2001 2:39 PM > To: Jonathan Rosenberg > Cc: 'iptel@lists.bell-labs.com' > Subject: Re: [IPTEL] the silence is deafening... > > > I'll bite :-) > > One question is whether we need one solution or whether different > solutions have different applications and trade-offs. After all, we have > RIPv2, OSPF, IS-IS and some vendor-proprietary protocols (as well as > simpler router discovery and advertisement via ICMP, IGMP and DHCP) as > interior/intra-domain routing protocols and BGPv4 as > exterior/inter-domain. > > Also, as with routing protocols, availability of broadcast/multicast > plays a role here. I would like to be able to optimize efficiency (or > reduce complexity) if multicast is available. As one real-life example I > happen to be familiar with, Internet2 is multicast-enabled and is > looking at how to distribute gateway information in the future. > > Also, the complexity of standardizing these things differ. In some > cases, it's a new protocol, in others a profile, in the third mainly a > new data structure (template). > > It might be helpful if the proponents/authors of each proposal could > abstract their proposal into a common set of properties, of which I > suggested a few above. (I'm sure there are many others I missed.) This > will tell us if the proposals are different mainly because they make > different assumptions on infrastructure and usage, and thus likely will > be complementary, or whether they are solving the same problem in the > same space. > > >From what I can tell, the number of parameters for each gateway appears > to be fairly small, so that translation between the schemes or to an > exterior scheme is reasonably simple. It is also not clear to me that > just blindly "exporting" the information wholesale to an inter-domain > scheme is desirable. If you consider the Internet2 example above, while > universities might make their facilities available in a > "peering"/mutual-aid fashion (no pay) to other universities, they may > have much more restrictive policies as to who gets to see what once it > leaves Internet2. > > > Jonathan Rosenberg wrote: > > > > Folks, > > > > Its been about 3 weeks since our call for proposals for "gateway > > registration" drafts ended. We actually have THREE proposals on the table: > > > > > http://search.ietf.org/internet-drafts/draft-roy-iptel-gw-server-discovery-0 > > 0.txt > > http://search.ietf.org/internet-drafts/draft-roy-iptel-itrp-00.txt > > > > http://search.ietf.org/internet-drafts/draft-rs-trip-gw-02.txt > > > > http://search.ietf.org/internet-drafts/draft-zhao-iptel-gwloc-slp-01.txt > > > > However, there has not been a single email post on this list with comments > > or questions. I'm not sure how to interpret that. Perhaps people are just > > busy (always true), or perhaps this is not important enough for anyone to > > take the time to focus on. However, if it is something that people do not > > feel is important enough to focus on, to the extent that they are willing > to > > post comments or push their proposals, then I could only conclude that it > is > > not something interesting enough to keep on the charter. I would be > > perfectly happy to finish the MIB and close down the group; I certainly > have > > plenty of other things to do. So, please do comment on these, and make > your > > opinions known. If there is no discussion within another two weeks, I will > > consider this consensus to remove the item from the charter and begin the > > process to make that happen. > > > > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > 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 Tue Oct 2 13:17:26 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21846 for ; Tue, 2 Oct 2001 13:17:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 867324437F; Tue, 2 Oct 2001 12:14:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by lists.bell-labs.com (Postfix) with ESMTP id 7085144336 for ; Tue, 2 Oct 2001 12:13:20 -0400 (EDT) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id NAA04267; Tue, 2 Oct 2001 13:16:36 -0400 (EDT) Message-ID: <3BB9F674.83723548@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Michael Hammer Cc: Weibin Zhao , "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] Use SLP for iptel-gwloc References: <3BB9D7F3.1DD53C22@cs.columbia.edu> <4.3.2.7.2.20011002130003.00aff670@cia.cisco.com> Content-Type: text/plain; charset=us-ascii 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 02 Oct 2001 13:16:36 -0400 Content-Transfer-Encoding: 7bit Michael Hammer wrote: > > Small observation: Are your units in U.S. dollars or Deutsch Marks or > Euros? > Columbia University laundry tokens, to be precise :-) Clearly, as discussed in the TRIP case, anything having to do with cost and prices is fraught with difficulties. I think there are two possible approaches (besides ditching the parameter): (1) Since the protocol under discussion is meant to be used within a single ITAD, the ITAD presumably has a single accounting currency, which is magically translated to whatever is appropriate (if anything) when this is exported to the world at large via TRIP - after adding a sufficient markup, taxes, license fees and shipping & handling, naturally. (2) Treat it like a cost or distance parameter in routing protocols, where smaller is better, but there's no assumption that it related to any physical unit, be it miles, milliseconds or dollars. (Or, similar to the preference value in DNS SRV, to cite another similar example.) Clearly, each ITAD can make this choice independently. Again, this is probably a more generic discussion, independent of the protocol chosen. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Oct 2 13:46:26 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22772 for ; Tue, 2 Oct 2001 13:46:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2A70944383; Tue, 2 Oct 2001 12:43:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169]) by lists.bell-labs.com (Postfix) with ESMTP id E1BD444380 for ; Tue, 2 Oct 2001 12:42:24 -0400 (EDT) Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA24992; Tue, 2 Oct 2001 13:45:48 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-145.cisco.com [161.44.87.145]) by cia.cisco.com (Mirapoint) with ESMTP id ARN08653; Tue, 2 Oct 2001 13:45:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20011002134316.00b62db0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Henning G. Schulzrinne" From: Michael Hammer Subject: Re: [IPTEL] Use SLP for iptel-gwloc Cc: Weibin Zhao , "'iptel@lists.bell-labs.com'" In-Reply-To: <3BB9F674.83723548@cs.columbia.edu> References: <3BB9D7F3.1DD53C22@cs.columbia.edu> <4.3.2.7.2.20011002130003.00aff670@cia.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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 02 Oct 2001 13:50:01 -0400 Henning, Sorry, but as an engineer, providing a measurement without defining the units is what leads to things hitting Mars rather than orbiting it. I don't think it is a good idea to imply limits on the scope of an ITAD. And if decisions are to be made based on cost, you can be sure the accountants will definitely want to know precisely what the cost is going to be when comparing data coming from two different gateways or ITADS. Mike At 01:16 PM 10/2/2001 -0400, Henning G. Schulzrinne wrote: >Michael Hammer wrote: > > > > Small observation: Are your units in U.S. dollars or Deutsch Marks or > > Euros? > > > >Columbia University laundry tokens, to be precise :-) > >Clearly, as discussed in the TRIP case, anything having to do with cost >and prices is fraught with difficulties. I think there are two possible >approaches (besides ditching the parameter): > >(1) Since the protocol under discussion is meant to be used within a >single ITAD, the ITAD presumably has a single accounting currency, which >is magically translated to whatever is appropriate (if anything) when >this is exported to the world at large via TRIP - after adding a >sufficient markup, taxes, license fees and shipping & handling, >naturally. > >(2) Treat it like a cost or distance parameter in routing protocols, >where smaller is better, but there's no assumption that it related to >any physical unit, be it miles, milliseconds or dollars. (Or, similar to >the preference value in DNS SRV, to cite another similar example.) > >Clearly, each ITAD can make this choice independently. > >Again, this is probably a more generic discussion, independent of the >protocol chosen. >-- >Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Oct 2 13:48:36 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22853 for ; Tue, 2 Oct 2001 13:48:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 95F174439F; Tue, 2 Oct 2001 12:45:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by lists.bell-labs.com (Postfix) with ESMTP id E4C4144380 for ; Tue, 2 Oct 2001 12:44:56 -0400 (EDT) Received: from gab200r1.ems.att.com ([135.37.94.32]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f92HlUk29024; Tue, 2 Oct 2001 13:47:30 -0400 (EDT) Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id NAA18174; Tue, 2 Oct 2001 13:47:43 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Oct 2001 13:47:29 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: Bob Penfield Cc: iptel@lists.bell-labs.com, "Henning G. Schulzrinne" , Jonathan Rosenberg Subject: RE: [IPTEL] the silence is deafening... MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 2 Oct 2001 13:47:25 -0400 Hi, Bob: Thanks for comments. Please see my comments provided below [RRR]: -----Original Message----- From: Bob Penfield [mailto:bpenfield@acmepacket.com] Sent: Tuesday, October 02, 2001 1:04 PM > > > -----Original Message----- > From: Anderson, Darby [mailto:Darby.Anderson@integratelecom.com] > > I suppose my only concerns as of present are: > > 1. Would this twist still be TRIP? > > [RRR] No, it is not TRIP although the message formats will be similar to > TRIP. You seem to be contradicting yourself. You want to use a single protocol, yet you claim TRIP is not appropriate. It seems to me that all of the routing information you are sharing with ITRP is nearly identical to that shared with TRIP, it just has a few extra atributes. Why can't we extend TRIP to support the additional attributes and the discovery mechanism needed. Or maybe use a separate discovery mechanism (maybe SLP). The SIP spec describes a way to find SIP servers that does not use SIP. [RRR] You could (technically) if you would change the TRIP protocol architecture. For example, all ITRP protocol properties can be used as a subset of TRIP (or special case of TRIP). The properties of ITRP have been mentioned in my earlier email (e.g., discovery, registration, use of UDP transport, email IDs, URL IDs, etc. are needed in TRIP). The heavy-weight part of TRIP will not be used for intra-domain communications. It is just a name change. In this way, we are in full agreement. I guess that this would be the best way to solve problem. If we all agree, I would vote to work along this line. (The another reason is that if we would modify SLP to accommodate the requirements, why can we not modify TRIP to do the same?) Once the routing information goes over the wall from the ITRP or SLP side to the TRIP side, it (at least some of it) is going to flooded to all the TRIP speakers in the ITAD. This seems to go against REQ 9. [RRR] You are right as I said above. However, we want TRIP should use UDP (not TCP-based flooding or limited broadcast - in inter-domain it makes sense where pre-provisioning [not automatic discovery] of the location servers is done in multi-carrier environment and, routes are propagated among the Location Servers [no GW information is transferred, rather is hidden behind the location server] - it is a different scenario - not applicable in intra-domain case). Another observation is that you can be almost sure that all discovery protocols need to UDP for multicasting. So, the support of UDP (or connectionless transport) almost becomes a indirect requirement. I find SLP bit more appealing than ITRP, but I have trouble with the need for every gateway to communicate with every routing server in the ITAD. This may be OK if there are just a few. [RRR] Like you, I also thought that SLP could be useful, but its many-to-many communications environment scared me so much that I was worried how we can build a usable large-scale network that can be managed meaningfully. Moreover, we may also add more things in the future for intra- and inter-domain protocol. In the end, we may face troubles to extend the SLP to meet our requirements. So, I have proposed ITRP (but I am willing to make it a subset of TRIP if we can extend TRIP as proposed). However, I am also open to see how far we can extend SLP to meet all requirements. Like you, I also like to have the best solution considering all alternatives. > > 2. If so, would this add much more developement time for the devlopement of > this protocol? > > [RRR] Any protocol that will be used for intra-domain communications will > have some new features. > I guess I have a problem with having to implement two different protocol to communicate virtually the same information. [RRR] I agree, but we need to meet the requirements of the intra-domain communications. The above suggestion of mine shows that we can also use "TRIP" if we could agree to accommodate those requirements as I explained earlier. > 3. In reguards to Section A, Subsection 5, does this make provisions for > redundancy/diversity of all network elements? (I.E. > G/W's,LocServ,RouteServ,Etc.) > > [RRR] If one likes to provision the GW or server to improve reliability, the > protocol will have the provision like this. > > > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Oct 2 13:59:35 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23490 for ; Tue, 2 Oct 2001 13:59:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8ED05443A4; Tue, 2 Oct 2001 12:56:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by lists.bell-labs.com (Postfix) with ESMTP id ACA7D44336 for ; Tue, 2 Oct 2001 12:55:32 -0400 (EDT) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id NAA06400; Tue, 2 Oct 2001 13:58:53 -0400 (EDT) Message-ID: <3BBA005D.FAB192AE@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Michael Hammer Cc: Weibin Zhao , "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] Use SLP for iptel-gwloc References: <3BB9D7F3.1DD53C22@cs.columbia.edu> <4.3.2.7.2.20011002130003.00aff670@cia.cisco.com> <4.3.2.7.2.20011002134316.00b62db0@cia.cisco.com> Content-Type: text/plain; charset=us-ascii 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 02 Oct 2001 13:58:53 -0400 Content-Transfer-Encoding: 7bit Michael Hammer wrote: > > Henning, > > Sorry, but as an engineer, providing a measurement without defining the > units is what leads to things hitting Mars rather than orbiting it. I > don't think it is a good idea to imply limits on the scope of an ITAD. And > if decisions are to be made based on cost, you can be sure the accountants > will definitely want to know precisely what the cost is going to be when > comparing data coming from two different gateways or ITADS. > If somebody can point to a registry of currency symbols (preferably one that includes Columbia laundry tokens...), this can certainly be added as a parameter. If I remember past discussions correctly, this territory is full of landmines, such as: - what about more complicated charges (first minute costs X, second minute costs Y, where Y < X or first minute is free); - unit of charging (second, minute, 6 seconds, etc.) - time-of-day dependencies (although these are less of an issue here since the advertisements are updated periodically in all of the protocols); etc. I'm agnostic here, but I suspect that without drawing pretty clear scope boundaries, this can turn into a "tariff expression language", which I don't think you'd want to engineer. That way also lie "restraint of trade" and other nasty things that the IETF does its very best to stay out of. (Basically, as soon as you specify anything specific that smacks of business models, you're favoring Joe's model over Jane's model, which may make Jane sufficiently unhappy to call a lawyer.) SLP (and the other proposals) is extensible so that you can add cost models appropriate for your customers. Then, if people don't like your notion of how costs are computed, they'll complain to your marketing folks, which I find preferable to talking to lawyers. (I'm not sure what would happen if somebody were to simply describe a template or extension as an informational RFC or IANA registration, without any blessing by the IETF; I suspect that that is the right thing to do in this case, if you want to go there.) -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Oct 2 14:46:26 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25125 for ; Tue, 2 Oct 2001 14:46:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1666844380; Tue, 2 Oct 2001 13:43:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169]) by lists.bell-labs.com (Postfix) with ESMTP id A8C5244336 for ; Tue, 2 Oct 2001 13:42:32 -0400 (EDT) Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA27581; Tue, 2 Oct 2001 14:45:55 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-145.cisco.com [161.44.87.145]) by cia.cisco.com (Mirapoint) with ESMTP id ARO00566; Tue, 2 Oct 2001 14:46:00 -0400 (EDT) Message-Id: <4.3.2.7.2.20011002144539.00b21ec0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Henning G. Schulzrinne" From: Michael Hammer Subject: Re: [IPTEL] Use SLP for iptel-gwloc Cc: Weibin Zhao , "'iptel@lists.bell-labs.com'" In-Reply-To: <3BBA005D.FAB192AE@cs.columbia.edu> References: <3BB9D7F3.1DD53C22@cs.columbia.edu> <4.3.2.7.2.20011002130003.00aff670@cia.cisco.com> <4.3.2.7.2.20011002134316.00b62db0@cia.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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 02 Oct 2001 14:50:09 -0400 Henning, I think I remember reading an Open Settlement Protocol (OSP) document that had some elements defined in XML. But, as you point out this would be much like the calendar discussion. Perhaps we could have an equivalent to the APR based on a 3-minute hold time. Likewise, to placate the lawyers, we should have a memo field in which we can put all sorts of disclaimers using a very small font size. :-) Mike At 01:58 PM 10/2/2001 -0400, Henning G. Schulzrinne wrote: >Michael Hammer wrote: > > > > Henning, > > > > Sorry, but as an engineer, providing a measurement without defining the > > units is what leads to things hitting Mars rather than orbiting it. I > > don't think it is a good idea to imply limits on the scope of an ITAD. And > > if decisions are to be made based on cost, you can be sure the accountants > > will definitely want to know precisely what the cost is going to be when > > comparing data coming from two different gateways or ITADS. > > > >If somebody can point to a registry of currency symbols (preferably one >that includes Columbia laundry tokens...), this can certainly be added >as a parameter. If I remember past discussions correctly, this territory >is full of landmines, such as: > >- what about more complicated charges (first minute costs X, second >minute costs Y, where Y < X or first minute is free); > >- unit of charging (second, minute, 6 seconds, etc.) > >- time-of-day dependencies (although these are less of an issue here >since the advertisements are updated periodically in all of the >protocols); > >etc. > >I'm agnostic here, but I suspect that without drawing pretty clear scope >boundaries, this can turn into a "tariff expression language", which I >don't think you'd want to engineer. That way also lie "restraint of >trade" and other nasty things that the IETF does its very best to stay >out of. (Basically, as soon as you specify anything specific that smacks >of business models, you're favoring Joe's model over Jane's model, which >may make Jane sufficiently unhappy to call a lawyer.) > >SLP (and the other proposals) is extensible so that you can add cost >models appropriate for your customers. Then, if people don't like your >notion of how costs are computed, they'll complain to your marketing >folks, which I find preferable to talking to lawyers. (I'm not sure what >would happen if somebody were to simply describe a template or extension >as an informational RFC or IANA registration, without any blessing by >the IETF; I suspect that that is the right thing to do in this case, if >you want to go there.) >-- >Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Oct 2 14:49:25 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25233 for ; Tue, 2 Oct 2001 14:49:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B70184439B; Tue, 2 Oct 2001 13:46:01 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mail.legerity.com (mail.legerity.com [209.217.157.66]) by lists.bell-labs.com (Postfix) with ESMTP id A6A354439B; Tue, 2 Oct 2001 13:45:01 -0400 (EDT) Received: from mopac.legerity.com (mopac.legerity.com [209.217.153.171]) by mail.legerity.com (8.11.4/8.11.4) with ESMTP id f92ImKC02913; Tue, 2 Oct 2001 13:48:20 -0500 Received: from notes01.legerity.com (localhost [127.0.0.1]) by mopac.legerity.com (8.9.3/8.9.3) with ESMTP id NAA15650; Tue, 2 Oct 2001 13:48:20 -0500 (CDT) Subject: Re: [IPTEL] Use SLP for iptel-gwloc To: "Henning G. Schulzrinne" Cc: iptel@lists.bell-labs.com, iptel-admin@lists.bell-labs.com, mhammer@cisco.com, zwb@cs.columbia.edu X-Mailer: Lotus Notes Release 5.0.2a November 23, 1999 Message-ID: From: Vijay.Davar@legerity.com X-MIMETrack: Serialize by Router on notes01/LGR(Release 5.0.8 |June 18, 2001) at 10/02/2001 01:48:19 PM MIME-Version: 1.0 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 2 Oct 2001 13:48:08 -0500 I commend the last note, given a choice lets stay agnostic here. "Henning G. Schulzrinne" To: Michael Hammer cc: Weibin Zhao , Sent by: "'iptel@lists.bell-labs.com'" iptel-admin@lists.bel l-labs.com Subject: Re: [IPTEL] Use SLP for iptel-gwloc 10/02/2001 12:58 PM Michael Hammer wrote: > > Henning, > > Sorry, but as an engineer, providing a measurement without defining the > units is what leads to things hitting Mars rather than orbiting it. I > don't think it is a good idea to imply limits on the scope of an ITAD. And > if decisions are to be made based on cost, you can be sure the accountants > will definitely want to know precisely what the cost is going to be when > comparing data coming from two different gateways or ITADS. > If somebody can point to a registry of currency symbols (preferably one that includes Columbia laundry tokens...), this can certainly be added as a parameter. If I remember past discussions correctly, this territory is full of landmines, such as: - what about more complicated charges (first minute costs X, second minute costs Y, where Y < X or first minute is free); - unit of charging (second, minute, 6 seconds, etc.) - time-of-day dependencies (although these are less of an issue here since the advertisements are updated periodically in all of the protocols); etc. I'm agnostic here, but I suspect that without drawing pretty clear scope boundaries, this can turn into a "tariff expression language", which I don't think you'd want to engineer. That way also lie "restraint of trade" and other nasty things that the IETF does its very best to stay out of. (Basically, as soon as you specify anything specific that smacks of business models, you're favoring Joe's model over Jane's model, which may make Jane sufficiently unhappy to call a lawyer.) SLP (and the other proposals) is extensible so that you can add cost models appropriate for your customers. Then, if people don't like your notion of how costs are computed, they'll complain to your marketing folks, which I find preferable to talking to lawyers. (I'm not sure what would happen if somebody were to simply describe a template or extension as an informational RFC or IANA registration, without any blessing by the IETF; I suspect that that is the right thing to do in this case, if you want to go there.) -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ 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 Tue Oct 2 17:36:31 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00384 for ; Tue, 2 Oct 2001 17:36:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 04F8C44368; Tue, 2 Oct 2001 16:33:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id DBAA944336 for ; Tue, 2 Oct 2001 16:32:23 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f92LZVP00516; Tue, 2 Oct 2001 14:35:31 -0700 (PDT) Received: from cisco.com (manjax-ultra5.cisco.com [128.107.138.93]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ABN11129 (AUTH manjax); Tue, 2 Oct 2001 14:35:13 -0700 (PDT) Message-ID: <3BBA3310.34E3308C@cisco.com> From: Manjunath Bangalore Organization: Cisco Systems Inc., San Jose, CA X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Henning G. Schulzrinne" Cc: iptel@lists.bell-labs.com, Weibin Zhao Subject: Re: [IPTEL] Parameters for gateway advertisements References: <3BB8FA00.FE65E239@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 02 Oct 2001 14:35:12 -0700 Content-Transfer-Encoding: 7bit An optional parameter that would be useful for the gateways to provide is the Carrier on which they terminate calls. For example: A gateway could advertise that it terminates a set of telephony prefixes on ATT and MCI, a different set of prefixes on MCI, SPRINT and another carrier JOE. This would enable gateway selection based on carrier preferences/policies. Regarding gateway capacity reporting, I second the idea that it is useful to advertise both Current Available Capacity and Total Available Capacity (Static Capacity) on the gateway. For example: Gateway 'A' could report as available 10 DS0 circuits available out of a total of 24 at a particular point in time, whereas Gateway 'B' could, for example, report 10 DS0 available out of a total of 96. The TRIP-Lite receiver (say, a Proxy) could make use of this information to achieve better load balancing of calls and is likely to be in a better position to identify a gateway that would have a higher probability of terminating a call successfully at that time. -Manjax "Henning G. Schulzrinne" wrote: > Beyond some notion of cost and maybe load or first-derivative of load, > are there other (optional) parameters that that are of interest for > gateways? > > One parameter commonly used to advertise international trunks is "answer > seizure ratio" (ASR), which apparently provides some indication as to > the loading of the system on the other side. Is this useful? Some other > QOS measure such as (post-dial delay) PDD? > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > 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 Wed Oct 3 09:58:33 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14825 for ; Wed, 3 Oct 2001 09:58:33 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2AE1D44338; Wed, 3 Oct 2001 08:55:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by lists.bell-labs.com (Postfix) with ESMTP id 9184E44336 for ; Wed, 3 Oct 2001 08:54:06 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A951C5660362; Wed, 03 Oct 2001 09:57:37 -0400 Message-ID: <00c901c14c12$6d5b3220$2300000a@acmepacket.com> From: "Bob Penfield" To: "IPTEL List" Subject: [IPTEL] Intra-domain routing ramblings MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 3 Oct 2001 09:50:56 -0400 Content-Transfer-Encoding: 7bit Hi all, I've been doing some thinking about the various intra-domain routing proposals, and I think there are a number of issues we need to work through. This is a TRIP-biased analysis. I guess my biggest concern with using something other than TRIP is the fact that once the routing information gets into a TRIP speaking LS, it will be flooded to all the other TRIP LSs in the ITAD. Ideally, this would be aggregated information where routes with common addresses would be combined. The question then is how "deep" into the ITAD do we want to advertise specific gateway route availability, capacity and so forth? Do we want to push the information to the "nearest" routing server LS, and require all calls to go thru that routing server? Or do we want to push it to all parts of the ITAD so that a call take only one proxy hop to get thru the ITAD to the desired gateway? I suppose it depends on how many LSs & proxies are in the ITAD. I see three levels of hierarchy in the routing information exchange: 1. Gateway to LS 2. Intra-ITAD LS exchanges 3. Inter-ITAD LS exchanges The concern is that the data exchanged at level 2 will duplicate the data exchanged at level 1, particularly if gateways advertise their routing information to multiple LSs in the ITAD. If the number of LSs in an ITAD is small and it was desirable to have calls routed to a gateway as soon as it entered the ITAD, using TRIP for level 1 would be the most efficient. Since, in this case, you want all the gateway information flooded to all LSs in the ITAD, you would not make the Gateway-to-LS a separate ITAD. The Gateway would inject routes to a local LSs, and those routes would be flooded to the rest of the LSs in the ITAD. The problem is that the currently described TRIP Decision Process requires that each LS pick 1 route (in essence pick a gateway) to put in its Loc-TRIB and use for routing calls. This goes against REQ 11. I think REQ 11 is important so that routing servers/LSs/proxies can make choices between gateways based on the current conditions and ensure a high probability of successful call setup. Another consideration is having different protocols for basically the same information is an extra burden on LS implementers and will affect the cost of products. I think one of the really good features of TRIP is that it combines the intra-domain capabilities of OSPF with the inter-domain capabilities of BGP into a single protocol. Discovery seems to be an important requirement for many people. IMHO, using a separate mechanism for discovering gateways and LSs is perfectly legitimate. SIP does not use SIP to discover SIP servers. We could use SLP or DNS, or define something new, or even add it to TRIP. That's just my opinion. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Oct 3 10:53:34 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17225 for ; Wed, 3 Oct 2001 10:53:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E4AC64434C; Wed, 3 Oct 2001 09:50:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mail.net2phone.com (mail.net2phone.com [216.53.3.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3979944336 for ; Wed, 3 Oct 2001 09:49:50 -0400 (EDT) Received: from mailsvr.net2phone.com (exchange.net2phone.com [216.53.60.1]) by mail.net2phone.com (8.11.5/8.11.5) with ESMTP id f93Er4P09657; Wed, 3 Oct 2001 10:53:04 -0400 (EDT) Received: by mailsvr with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Oct 2001 10:53:16 -0400 Message-ID: <6F46FABB90ABD411BD690002B3152FB96BF480@lkwmail01> From: Jeffrey Skelton To: "'Henning G. Schulzrinne'" , Michael Hammer Cc: Weibin Zhao , "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] Use SLP for iptel-gwloc MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 3 Oct 2001 10:50:47 -0400 Without representing units, then is the assumption that the scope for useful comparison of cost values is within an ITAD? -----Original Message----- From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Tuesday, October 02, 2001 1:59 PM To: Michael Hammer Cc: Weibin Zhao; 'iptel@lists.bell-labs.com' Subject: Re: [IPTEL] Use SLP for iptel-gwloc Michael Hammer wrote: > > Henning, > > Sorry, but as an engineer, providing a measurement without defining the > units is what leads to things hitting Mars rather than orbiting it. I > don't think it is a good idea to imply limits on the scope of an ITAD. And > if decisions are to be made based on cost, you can be sure the accountants > will definitely want to know precisely what the cost is going to be when > comparing data coming from two different gateways or ITADS. > If somebody can point to a registry of currency symbols (preferably one that includes Columbia laundry tokens...), this can certainly be added as a parameter. If I remember past discussions correctly, this territory is full of landmines, such as: - what about more complicated charges (first minute costs X, second minute costs Y, where Y < X or first minute is free); - unit of charging (second, minute, 6 seconds, etc.) - time-of-day dependencies (although these are less of an issue here since the advertisements are updated periodically in all of the protocols); etc. I'm agnostic here, but I suspect that without drawing pretty clear scope boundaries, this can turn into a "tariff expression language", which I don't think you'd want to engineer. That way also lie "restraint of trade" and other nasty things that the IETF does its very best to stay out of. (Basically, as soon as you specify anything specific that smacks of business models, you're favoring Joe's model over Jane's model, which may make Jane sufficiently unhappy to call a lawyer.) SLP (and the other proposals) is extensible so that you can add cost models appropriate for your customers. Then, if people don't like your notion of how costs are computed, they'll complain to your marketing folks, which I find preferable to talking to lawyers. (I'm not sure what would happen if somebody were to simply describe a template or extension as an informational RFC or IANA registration, without any blessing by the IETF; I suspect that that is the right thing to do in this case, if you want to go there.) -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ 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 Wed Oct 3 11:00:36 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17600 for ; Wed, 3 Oct 2001 11:00:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 86873443AB; Wed, 3 Oct 2001 09:57:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by lists.bell-labs.com (Postfix) with ESMTP id 25D5B443A7 for ; Wed, 3 Oct 2001 09:56:21 -0400 (EDT) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id KAA27030; Wed, 3 Oct 2001 10:59:52 -0400 (EDT) Message-ID: <3BBB27E8.7F8BBE09@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Bob Penfield Cc: IPTEL List Subject: Re: [IPTEL] Intra-domain routing ramblings References: <00c901c14c12$6d5b3220$2300000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 03 Oct 2001 10:59:52 -0400 Content-Transfer-Encoding: 7bit In addition to the model you posit, I believe there are probably several models that could arise: - In many situations, people won't need or want TRIP. After all, most organizations in the world are quite happy without BGP, but do need OSPF, RIP, IS-IS, etc. - In other situations, you are going to have a single point (LS) per ITAD that speaks TRIP, again similar to the arrangement for many organizations with a single BGP peering arrangement. In that case, that point is likely to do all kinds of policy translations and information filtering in any event, so that having two protocols is a minor inconvenience at best. You are not just going to be able to byte-copy interior information to the externally advertised TRIP announcements. [I'm avoiding the term LS since this term is also used for non-TRIP things.] Also, an interior protocol can make different choices. For example, it's much easier to agree on some kind of internal charging indication for a gateway/prefix, without worrying about coming up with one that fits every peer and passes Department of Justice muster. This, again, argues, I believe, that finding a one-size-fits-all solution is not likely to be viable in this case. It is important to make sure that information needed by TRIP can be conveyed by the interior protocol, but the amount of per-prefix information in TRIP that people seem to be able to agree on is so small at this point that this seems to be hardly a consideration. Bob Penfield wrote: > > Hi all, > > I've been doing some thinking about the various intra-domain routing > proposals, and I think there are a number of issues we need to work through. > This is a TRIP-biased analysis. > > I guess my biggest concern with using something other than TRIP is the fact > that once the routing information gets into a TRIP speaking LS, it will be > flooded to all the other TRIP LSs in the ITAD. Ideally, this would be > aggregated information where routes with common addresses would be combined. > The question then is how "deep" into the ITAD do we want to advertise > specific gateway route availability, capacity and so forth? Do we want to > push the information to the "nearest" routing server LS, and require all > calls to go thru that routing server? Or do we want to push it to all parts > of the ITAD so that a call take only one proxy hop to get thru the ITAD to > the desired gateway? I suppose it depends on how many LSs & proxies are in > the ITAD. > > I see three levels of hierarchy in the routing information exchange: > > 1. Gateway to LS > 2. Intra-ITAD LS exchanges > 3. Inter-ITAD LS exchanges > > The concern is that the data exchanged at level 2 will duplicate the data > exchanged at level 1, particularly if gateways advertise their routing > information to multiple LSs in the ITAD. > > If the number of LSs in an ITAD is small and it was desirable to have calls > routed to a gateway as soon as it entered the ITAD, using TRIP for level 1 > would be the most efficient. Since, in this case, you want all the gateway > information flooded to all LSs in the ITAD, you would not make the > Gateway-to-LS a separate ITAD. The Gateway would inject routes to a local > LSs, and those routes would be flooded to the rest of the LSs in the ITAD. > The problem is that the currently described TRIP Decision Process requires > that each LS pick 1 route (in essence pick a gateway) to put in its Loc-TRIB > and use for routing calls. This goes against REQ 11. I think REQ 11 is > important so that routing servers/LSs/proxies can make choices between > gateways based on the current conditions and ensure a high probability of > successful call setup. > > Another consideration is having different protocols for basically the same > information is an extra burden on LS implementers and will affect the cost > of products. I think one of the really good features of TRIP is that it > combines the intra-domain capabilities of OSPF with the inter-domain > capabilities of BGP into a single protocol. > > Discovery seems to be an important requirement for many people. IMHO, using > a separate mechanism for discovering gateways and LSs is perfectly > legitimate. SIP does not use SIP to discover SIP servers. We could use SLP > or DNS, or define something new, or even add it to TRIP. > > That's just my opinion. > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Oct 3 11:04:40 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17779 for ; Wed, 3 Oct 2001 11:04:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A7DF6443B7; Wed, 3 Oct 2001 10:01:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by lists.bell-labs.com (Postfix) with ESMTP id 17021443B5 for ; Wed, 3 Oct 2001 10:00:42 -0400 (EDT) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id LAA27254; Wed, 3 Oct 2001 11:04:09 -0400 (EDT) Message-ID: <3BBB28E9.4A2DC639@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Jeffrey Skelton Cc: Michael Hammer , Weibin Zhao , "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] Use SLP for iptel-gwloc References: <6F46FABB90ABD411BD690002B3152FB96BF480@lkwmail01> Content-Type: text/plain; charset=us-ascii 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 03 Oct 2001 11:04:09 -0400 Content-Transfer-Encoding: 7bit Jeffrey Skelton wrote: > > Without representing units, then is the assumption that the scope for useful > comparison of cost values is within an ITAD? That's at least my assumption. It may well be that there's an entity that translates these numbers into something visible to the outside, but as far as I know, TRIP doesn't have a means of indicating dollars-and-cents "billable" cost information, either, so it's not clear how that would work (except by some vendor-defined attribute). This does not preclude somebody defining attributes that are more specific or concrete; I suspect that industry associations with more lawyers at hand and a more business-oriented focus are better places for this than the IETF. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Oct 3 11:53:33 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19228 for ; Wed, 3 Oct 2001 11:53:33 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C1E6F443A7; Wed, 3 Oct 2001 10:50:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by lists.bell-labs.com (Postfix) with ESMTP id B707944336 for ; Wed, 3 Oct 2001 10:49:52 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f93FrKk10193; Wed, 3 Oct 2001 11:53:21 -0400 (EDT) Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id LAA00970; Wed, 3 Oct 2001 11:51:59 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Oct 2001 11:53:19 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: Bob Penfield , IPTEL List Subject: RE: [IPTEL] Intra-domain routing ramblings MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 3 Oct 2001 11:24:52 -0400 Please see my response provide below [RRR]: -----Original Message----- From: Bob Penfield [mailto:bpenfield@acmepacket.com] Sent: Wednesday, October 03, 2001 9:51 AM To: IPTEL List Subject: [IPTEL] Intra-domain routing ramblings Hi all, I've been doing some thinking about the various intra-domain routing proposals, and I think there are a number of issues we need to work through. This is a TRIP-biased analysis. I guess my biggest concern with using something other than TRIP is the fact that once the routing information gets into a TRIP speaking LS, it will be flooded to all the other TRIP LSs in the ITAD. Ideally, this would be aggregated information where routes with common addresses would be combined. The question then is how "deep" into the ITAD do we want to advertise specific gateway route availability, capacity and so forth? Do we want to push the information to the "nearest" routing server LS, and require all calls to go thru that routing server? Or do we want to push it to all parts of the ITAD so that a call take only one proxy hop to get thru the ITAD to the desired gateway? I suppose it depends on how many LSs & proxies are in the ITAD. [RRR] I agree that it would be better if we could use the same protocol like TRIP for the intra-domain avoiding its heavy-weight part. In fact, ITRP proposal has been like this because it can be made a sub-set of TRIP. We can extend TRIP, as suggested in ITRP, for one additional message for "discovery" while the other messages of TRIP can be extended to meet the simple requirements of intra-domain communications (e.g., ITRP messages mirror the TRIP messages) without using its complex route propagation part. In intra-domain, we need a couple of things for address information: Telephone numbers, Email IDs, URL IDs, etc. associated with a GW. (In inter-domain TRIP, routes are propagated among the LSs and no GW information is propagated.) In intra-domain, we need to associate a particular GW where the call will be directed for a given telephone number, Email ID, URL ID, or other numbers. For efficiency purpose, we may use UDP transport as well (but TCP can also be used). I see three levels of hierarchy in the routing information exchange: 1. Gateway to LS 2. Intra-ITAD LS exchanges 3. Inter-ITAD LS exchanges [RRR] Yes, this hierarchy is OK (also indicated in ITRP proposal). However, it is also possible that a call may come to a LS, and a LS may not have the information of the GW, and it may also try to discover a GW within the ITAD. Both inter- and intra-ITAD communications will be complementing each other although they are "logically de-coupled" from protocol point of view. The concern is that the data exchanged at level 2 will duplicate the data exchanged at level 1, particularly if gateways advertise their routing information to multiple LSs in the ITAD. [RRR] It depends on configurations. For example, a given set GWs will be communicating with a given LS and a LS will be communicating with all other LSs. In this way, all LSs will make sure that they will have the same information (e.g., ITRP proposal describes this). One important thing is that TRIP hides the GW information behind the LS. In intra-ITAD, a LS does not need to hide the GW information (e.g., ITRP proposal). In ITRP (unlike TRIP), each LS knows which GW needs to be contacted for each destination address (e.g., Telephone number, Email ID, URL ID, etc.) after exchanging the information among themselves. If the number of LSs in an ITAD is small and it was desirable to have calls routed to a gateway as soon as it entered the ITAD, using TRIP for level 1 would be the most efficient. Since, in this case, you want all the gateway information flooded to all LSs in the ITAD, you would not make the Gateway-to-LS a separate ITAD. The Gateway would inject routes to a local LSs, and those routes would be flooded to the rest of the LSs in the ITAD. The problem is that the currently described TRIP Decision Process requires that each LS pick 1 route (in essence pick a gateway) to put in its Loc-TRIB and use for routing calls. This goes against REQ 11. I think REQ 11 is important so that routing servers/LSs/proxies can make choices between gateways based on the current conditions and ensure a high probability of successful call setup. [RRR] There is a two-step process: Intra-ITAD and Inter-ITAD. For intra-ITAD, our main focus is how to find the GW for a given destination address (Telephone number, Email ID, URL ID, or others) and, a LS will be able to provide it. The next question is: Where do I get the GW information if it is not within the ITAD? This is not directly answered in the intra-ITAD protocol. (One can assume that a LS gets it using the inter-domain TRIP protocol if it is telephony GW. Now, others can answer how TRIP is intended to be used, but it is out-of-scope of intra-domain protocol.) The only thing that we need to make sure: A LS will get the necessary information for TRIP. Another consideration is having different protocols for basically the same information is an extra burden on LS implementers and will affect the cost of products. I think one of the really good features of TRIP is that it combines the intra-domain capabilities of OSPF with the inter-domain capabilities of BGP into a single protocol. [RRR] I guess that it is not an extra burden per se. We need to satisfy the requirements of the intra-ITAD communications environment. Let us not use the example of the routing protocol directly because we are just selecting a GW for given destination address (not the "route" per se). Discovery seems to be an important requirement for many people. IMHO, using a separate mechanism for discovering gateways and LSs is perfectly legitimate. SIP does not use SIP to discover SIP servers. We could use SLP or DNS, or define something new, or even add it to TRIP. [RRR] Yes, discovery is the important piece of the puzzle for the intra-ITAD communications. We can address this through extending TRIP by one additional message known as "DISCOVERY" as suggested above (e.g., ITRP proposal). [RRR] In addition, we will also see some alternate proposals and, will find the best of all alternatives. That's just my opinion. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.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 Thu Oct 4 10:59:43 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15312 for ; Thu, 4 Oct 2001 10:59:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D65CC443BD; Thu, 4 Oct 2001 09:56:01 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id A233E443B3 for ; Thu, 4 Oct 2001 09:55:37 -0400 (EDT) Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA29763 for ; Thu, 4 Oct 2001 10:59:17 -0400 (EDT) From: Weibin Zhao X-X-Sender: To: "'iptel@lists.bell-labs.com'" Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=NextPart Content-ID: Subject: [IPTEL] I-D ACTION:draft-zhao-iptel-gwloc-slp-02.txt (fwd) 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 4 Oct 2001 10:59:17 -0400 (EDT) This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --NextPart Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hello all, We updated the template for iptel-gw service. As now, the attributes are as follows: total-capacity, remaining-capacity, prefix-list, cost-list, asr-list. We can add more attributes if needed. Comments on this draft are welcome. Thanks. -Weibin ---------- Forwarded message ---------- Date: Thu, 04 Oct 2001 07:03:33 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ;;:@cs.columbia.edu; Subject: I-D ACTION:draft-zhao-iptel-gwloc-slp-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Locating Internet Telephony Gateways via SLP Author(s) : W. Zhao, H. Schulzrinne Filename : draft-zhao-iptel-gwloc-slp-02.txt Pages : 11 Date : 03-Oct-01 This document describes how to use the Service Location Protocol (SLP) to locate Internet telephony gateways. It defines the 'service:iptel-gw:' template for the Internet telephony gateway service, and discusses the different usage scenarios and the applicability of SLP for the Internet telephony gateway location. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zhao-iptel-gwloc-slp-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zhao-iptel-gwloc-slp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zhao-iptel-gwloc-slp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY=OtherAccess Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-ID: --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-zhao-iptel-gwloc-slp-02.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-ID: --OtherAccess-- --NextPart-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Oct 4 17:19:43 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25116 for ; Thu, 4 Oct 2001 17:19:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 924AC443C1; Thu, 4 Oct 2001 16:16:01 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by lists.bell-labs.com (Postfix) with ESMTP id C408C443B3 for ; Thu, 4 Oct 2001 16:15:49 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f94LHPC14017; Thu, 4 Oct 2001 14:17:26 -0700 (PDT) Received: from cisco.com (manjax-ultra5.cisco.com [128.107.138.93]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AAF47912 (AUTH manjax); Thu, 4 Oct 2001 14:19:27 -0700 (PDT) Message-ID: <3BBCD260.76051995@cisco.com> From: Manjunath Bangalore Organization: Cisco Systems Inc., San Jose, CA X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bob Penfield Cc: IPTEL List Subject: Re: [IPTEL] Intra-domain routing ramblings References: <00c901c14c12$6d5b3220$2300000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 04 Oct 2001 14:19:28 -0700 Content-Transfer-Encoding: 7bit Hi Bob, Some thoughts on the propogation of routes from level 1 to level 2 in the heirarchy that you brought out: Bob Penfield wrote: > Hi all, > > I've been doing some thinking about the various intra-domain routing > proposals, and I think there are a number of issues we need to work through. > This is a TRIP-biased analysis. > > I guess my biggest concern with using something other than TRIP is the fact > that once the routing information gets into a TRIP speaking LS, it will be > flooded to all the other TRIP LSs in the ITAD. Ideally, this would be > aggregated information where routes with common addresses would be combined. > The question then is how "deep" into the ITAD do we want to advertise > specific gateway route availability, capacity and so forth? Do we want to > push the information to the "nearest" routing server LS, and require all > calls to go thru that routing server? Or do we want to push it to all parts > of the ITAD so that a call take only one proxy hop to get thru the ITAD to > the desired gateway? I suppose it depends on how many LSs & proxies are in > the ITAD. > My thinking is that gateway routes should be propogated only to the "nearest" TRIP LS, (maybe to an additional LS or two for redundancy purposes). If gateway routes were to be advertised deeper into the ITAD, the model would not scale as the number of gateways in the ITAD increases and will result in significant additional traffic. Another important consideration that would not make that model feasible is that, gateway routes carry capacity information, and if several LSs look at the same capacity information in selection of gateways to terminate calls, that can result in inconsistent assignment of gateways. Ideally, there should be only one controlling entity (LS/Proxy) that should be reading from the capacity information in the gateway routes for identifying gateways to terminate calls and rationing the available capacities from a collection of alternative gateway routes to achieve good load balancing to fairly distribute calls among the different gateways. When gateways advertise routes to the nearest first-hop LS, the LS would propogate these routes further into the ITAD after modifying the "Next Signaling Hop" to point to the Proxy/Gatekeeper (for instance) signaling entity controlling the gateways and one that has access to the capacity information advertised by the gateways. Thanks, -Manjax > > I see three levels of hierarchy in the routing information exchange: > > 1. Gateway to LS > 2. Intra-ITAD LS exchanges > 3. Inter-ITAD LS exchanges > > The concern is that the data exchanged at level 2 will duplicate the data > exchanged at level 1, particularly if gateways advertise their routing > information to multiple LSs in the ITAD. > > If the number of LSs in an ITAD is small and it was desirable to have calls > routed to a gateway as soon as it entered the ITAD, using TRIP for level 1 > would be the most efficient. Since, in this case, you want all the gateway > information flooded to all LSs in the ITAD, you would not make the > Gateway-to-LS a separate ITAD. The Gateway would inject routes to a local > LSs, and those routes would be flooded to the rest of the LSs in the ITAD. > The problem is that the currently described TRIP Decision Process requires > that each LS pick 1 route (in essence pick a gateway) to put in its Loc-TRIB > and use for routing calls. This goes against REQ 11. I think REQ 11 is > important so that routing servers/LSs/proxies can make choices between > gateways based on the current conditions and ensure a high probability of > successful call setup. > > Another consideration is having different protocols for basically the same > information is an extra burden on LS implementers and will affect the cost > of products. I think one of the really good features of TRIP is that it > combines the intra-domain capabilities of OSPF with the inter-domain > capabilities of BGP into a single protocol. > > Discovery seems to be an important requirement for many people. IMHO, using > a separate mechanism for discovering gateways and LSs is perfectly > legitimate. SIP does not use SIP to discover SIP servers. We could use SLP > or DNS, or define something new, or even add it to TRIP. > > That's just my opinion. > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.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 Oct 5 15:44:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29958 for ; Fri, 5 Oct 2001 15:44:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5171F44378; Fri, 5 Oct 2001 14:40:10 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ss8mail1.ss8ott (mail.ss8.ca [209.87.228.147]) by lists.bell-labs.com (Postfix) with ESMTP id 47A854436E for ; Fri, 5 Oct 2001 13:09:21 -0400 (EDT) Received: by mail.ss8.ca with Internet Mail Service (5.5.2650.21) id ; Fri, 5 Oct 2001 14:13:38 -0400 Message-ID: <8BAF8B40C4D2D411ADC300508BD63D69ABA3DC@mail.ss8.ca> From: David Zinman To: "'Kevin Lingle'" , iptel@lists.bell-labs.com Cc: Dave Walker , Jianping Jiang Subject: RE: [Fwd: [Fwd: [IPTEL] FW: I-DACTION:draft-ietf-iptel-trip-mib-0 0.txt]] MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14DC9.7240253A" 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 5 Oct 2001 14:13:34 -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_01C14DC9.7240253A Content-Type: text/plain; charset="iso-8859-1" Kevin, Thanks for you detailed comments! Responses inline. Cheers, DZ -----Original Message----- From: Kevin Lingle [ mailto:klingle@cisco.com] Sent: Friday, August 31, 2001 11:42 AM To: iptel@lists.bell-labs.com Subject: RE: [Fwd: [Fwd: [IPTEL] FW: I-DACTION:draft-ietf-iptel-trip-mib-0 0.txt]] hi, i have some comments on the trip mib. i'm not a trip expert, so consider most comments from a general snmp/mib perspective. my comments are embedded below. this is only a partial review. i made it up to tripRouteTable. i'll send more comments early next week. the above wg information is nice, but i think you should list it outside the mib module (elsewhere in the draft doc) since it is subject to change. the list of co-authors is presumed to be more stable, so it's good to keep in the mib. [DZ] Done. > > Mailing List > ============ > iptel-admin@lists.bell-labs.com > > General information about the mailing list is at: > http://lists.bell-labs.com/mailman/listinfo/iptel/ > > Archives: > http://lists.bell-labs.com/pipermail/iptel/" same basic comment about this maillist section. although you should provide one "Email" contact other than the authors. the iptel list might be a good common list for trip mib discussion or create your own trip-mib list. for sip mib work, we used yahoogroups.com, but now as we get into last call, the comments have been that ietf frowns on such list servers and we are using the general discussion list for sip. try and pick a list that will be available longterm and salient to trip or specific to the trip-mib. that way it won't need to be changed repeatedly in the mib... a task that will be harder once this is an rfc. [DZ] We discussed the need for a separate list last December but it was decided that it was not necessary. > > DESCRIPTION > "The MIB module describing Telephony Routing > over IP (TRIP)" i think you should add some more description here of what trip is and does. [DZ] I agree. > REVISION "200102260000Z" > DESCRIPTION > "The initial revision of this MIB module was > published as draft-zinman-trip-mib-00.txt." remove this reference to a old draft. it will be of no use shortly and certainly no down the road in a year or two. just make this revision "The initial version of this MIB..." [DZ] Done. > ::= { mib-2 } -- to be assigned by IANA > > -- > -- Textual Conventions > -- > TripItad ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "The values for identifying the IP Telephony > Administrative Domain." add "(ITAD)" to formally introduce the acryonym. [DZ] Done. > SYNTAX Unsigned32 (0..4294967295) > > TripId ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "The range of legal values for a TRIP Identifier." say some more about what a trip identifier is and is used for. [DZ] Agree. > SYNTAX Unsigned32 (0..4294967295) > > TripAppProtocol ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "The application protocol used for communication with > TRIP LS's. Protocol defined in this document are: what's an "LS" - expand acryonmym on first use. [DZ] Done. > tripSupProtSIP > tripSupProtH323Q931 > tripSupProtH323RAS > tripSupProtH323ANNEXG. > > Users can add their own application protocol types by defining > a TripAppProtocol type in a private specification." > SYNTAX OBJECT IDENTIFIER > > TripAddressFamily ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "A type of address for a TRIP route. Address families defined > within this document are: change "document" to "MIB module". [DZ]Done. > tripAddrFamilyDecimal > tripAddrFamilyPentadecimal > tripAddrFamilyE164. > > Users can add their own address family types by defining a > TripAddressFamily type in a private specification." > SYNTAX OBJECT IDENTIFIER > > tripMIBNotifications OBJECT IDENTIFIER ::= { tripMIB 0 } > tripMIBObjects OBJECT IDENTIFIER ::= { tripMIB 1 } > tripMIBConformance OBJECT IDENTIFIER ::= { tripMIB 2 } > tripMIBCompliance OBJECT IDENTIFIER ::= { tripMIBConformance 1 } > tripMIBGroups OBJECT IDENTIFIER ::= { tripMIBConformance 2 } > > -- > -- Supported protocols > -- > tripSupportedProtocols OBJECT IDENTIFIER ::= { tripMIBObjects 100 } i think it would be cleaner to define these (and the addr family) oids directly off tripMIB rather than picking some arbitrarily high oid space under tripMIBObjects. eg, tripSupportedProtocols OBJECT IDENTIFIER ::= { tripMIB 3 } tripAddressFamilies OBJECT IDENTIFIER ::= { tripMIB 4 } [DZ] I have changed tripSupportedProtocols and tripAddressFamilies to OBJECT-IDENTITY because it is more descriptive of their function. Is it ok to have these under one more level? For example tripStaticConfigObjects OBJECT IDENTIFIER ::= { tripMIB 3 } tripSupportedProtocols OBJECT-IDENTITY STATUS current DESCRIPTION "Registration point for the protocols supported by TRIP." ::= { tripStaticConfigObjects 1 } tripAddressFamilies OBJECT-IDENTITY STATUS current DESCRIPTION "Registration point for the address families supported by TRIP." ::= { tripStaticConfigObjects 2 } > > tripSupProtSIP > OBJECT IDENTIFIER ::= { tripSupportedProtocols 1 } > tripSupProtH323Q931 > OBJECT IDENTIFIER ::= { tripSupportedProtocols 2 } > tripSupProtH323RAS > OBJECT IDENTIFIER ::= { tripSupportedProtocols 3 } > tripSupProtH323ANNEXG > OBJECT IDENTIFIER ::= { tripSupportedProtocols 4 } > > -- > -- Address Families > -- > tripAddressFamilies OBJECT IDENTIFIER ::= { tripMIBObjects 101 } > > tripAddrFamilyDecimal > OBJECT IDENTIFIER ::= { tripAddressFamilies 1 } > tripAddrFamilyPentadecimal > OBJECT IDENTIFIER ::= { tripAddressFamilies 2 } > tripAddrFamilyE164 > OBJECT IDENTIFIER ::= { tripAddressFamilies 3 } > > -- > -- tripCfgTable > -- > tripCfgTable OBJECT-TYPE > SYNTAX SEQUENCE OF TripCfgEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This table contains the common configuration objects > applicable to all TRIP entities. Each row represents > those objects for a particular TRIP LS present in > this system. The instances of TRIP LS's are > uniquely identified by applIndex." the description here indicates that the info in this table is wrt the trip ls present on this system. the use of the work "peer" in later descriptions makes me think the information might be wrt a peer trip ls elsewhere in the network. perhaps all trip entities are referred to as Peers and you are still actually talking about the local trip entity. it's a bit confusing, can that be clarified? [DZ] Yes it is a bit confusing. "All TRIP entities" refer to all the local TRIP applications referenced by the applIndex. I will try to make this clearer. > ::= { tripMIBObjects 1 } > > tripCfgEntry OBJECT-TYPE > SYNTAX TripCfgEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A row of common configuration." > INDEX { applIndex } > ::= { tripCfgTable 1 } > > TripCfgEntry ::= > SEQUENCE { > tripProtocolVersion Integer32, > tripLocalItad TripItad, > tripIdentifier TripId, > tripOperStatus INTEGER, > tripAdminStatus INTEGER, > tripLocalAddrIAddrType InetAddressType, > tripLocalAddr InetAddress, > tripLocalPort Integer32, > tripMinItadOriginationInterval Integer32, > tripMinRouteAdvertisementInterval Integer32, > tripMaxPurgeTime Integer32, > tripDisableTime Integer32, > tripSendReceiveMode INTEGER > } > > tripProtocolVersion OBJECT-TYPE > SYNTAX Integer32 (1..255) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object will reflect the version of TRIP > supported by this system. It follows the same > format as TRIP version information contained > in the TRIP messages generated by this TRIP entity > as dictated by draft-ietf-iptel-trip-07.txt." try to avoid referencing I-D documents. the information will be stale long before these mib object definitions are obsolete. if you must for clarity, i understand, but expect to have to remove/revise it in later revisions of the mib and put it in a REFERENCE clause rather than the DESCRIPTION. the DESCRIPTION here could just say "... as dictated by the TRIP standard." [DZ] Done. > ::= { tripCfgEntry 1 } > > tripLocalItad OBJECT-TYPE > SYNTAX TripItad > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The Local Internet Telephony Administrative domain." > ::= { tripCfgEntry 2 } > > tripIdentifier OBJECT-TYPE > SYNTAX TripId > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The object that identifies this TRIP Client." > ::= { tripCfgEntry 3 } > > tripAdminStatus OBJECT-TYPE > SYNTAX INTEGER { > up(1), > down(2) > } > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The desired TRIP state. > > up(1) : Set the application to normal operation. > > down(2): Set the application to a state where it will not > process TRIP messages." gee, i wish we could simplify our sip mib admin status down to this ;) > ::= { tripCfgEntry 4 } > > tripOperStatus OBJECT-TYPE > SYNTAX INTEGER { > up(1), > down(2) > } > MAX-ACCESS read-write oper status should be read-only. > STATUS current > DESCRIPTION > "The current operational state of the TRIP protocol. > > up(1) : The application is operating normally, and > is processing (receiving and possibly > issuing) TRIP requests and responses. > > down(2): The application is currently unable to > process TRIP messages due to a fault or if > TRIP is in an initialization state. > > If tripAdminStatus is down(2) then tripOperStatus should be > down(2). If tripAdminStatus is changed to up(1) then > tripOperStatus should change to up(1) if there is no fault > that prevents the TRIP protocol from moving to the up(1) > state." consider adding another oper state that the appl can be in if there is a fault of some sort. [DZ] do we really need a new state for faulty? Faults will covered by the notifications. > ::= { tripCfgEntry 5 } > > tripLocalAddrIAddrType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The type of Inet Address of the tripLocalAddr." > REFERENCE > "RFC 2851, section 3." > ::= { tripCfgEntry 6 } > > tripLocalAddr OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The IP address of this entry's TRIP peer connection." here is one of the confusing spots... is this an address of a peer trip entity? if so, then the use of "Local" in the obj descriptor seems strange. [DZ] I agree. tripAddr is better. Same for tripPort, tripItad... > REFERENCE > "RFC 2851, section 3." > ::= { tripCfgEntry 7 } > > tripLocalPort OBJECT-TYPE > SYNTAX Integer32 (1..65535) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The local port that this entry's TRIP peer is using." again, i'm a bit confused. the description talks about a trip peer using this port, but the "Local" reference in the obj has me confused. also, is this s tcp/udp port or an "interface" on the box? port can be an ambiguous term in the world of networking, so please be more specific. [DZ] agree. > ::= { tripCfgEntry 8 } > > tripMinItadOriginationInterval OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) any reason not to use the SNMPv2-TC TimeInterval ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A period of time, measured in units of 0.01 seconds." SYNTAX INTEGER (0..2147483647) ? is the 0 value of TimeInterval a problem? > UNITS "Seconds" if TimeInterval was used, UNITS would either come out of the mib or need to reflect "hundreths of a second". [DZ] Since we don't need the granularity of "hundredths of a second" and this object starts at 1, I think that it would more descriptive to leave the object as is. > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "Amount of time that must elapse between advertisement > of update message that report changes within the > Location Server's own ITAD." > DEFVAL { 30 } DEFVAL would go to 3000 if TimeInterval used. > ::= { tripCfgEntry 9 } > > tripMinRouteAdvertisementInterval OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) same comment wrt TimeInterval TC. [DZ] See above. > UNITS "Seconds" > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "Specifies minimal interval between successive > advertisement to a particular destination from an LS." > DEFVAL { 30 } > ::= { tripCfgEntry 10 } > > tripMaxPurgeTime OBJECT-TYPE > SYNTAX Integer32 (1..65535) same comment wrt TimeInterval TC. > UNITS "Seconds" > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "Indicate the interval that the location server must > maintain routes marked as withdrawn in its database." > DEFVAL { 10 } > ::= { tripCfgEntry 11 } > > tripDisableTime OBJECT-TYPE > SYNTAX Integer32 (1..65535) same comment wrt TimeInterval TC. > UNITS "Seconds" > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "Indicate the interval that the TRIP module of the > location server must be disabled while routes > originated by this location server with high > sequence numbers can be removed." > DEFVAL { 180 } > ::= { tripCfgEntry 12 } > > tripSendReceiveMode OBJECT-TYPE > SYNTAX INTEGER { > sendReceive(1), > sendOnly(2), > receiveOnly(3) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The operational mode of this peer." the trip entity running on this system?? [DZ] Yes. > ::= { tripCfgEntry 13 } > > -- > -- tripSupportedCommunityTable > -- > > tripSupportedCommunityTable OBJECT-TYPE > SYNTAX SEQUENCE OF TripSupportedCommunityEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The list of TRIP communities that this LS supports. A TRIP > community is a group of destinations that share some common > property. property -> properties. [DZ] agree. > > The TRIP Communities attribute is used to group destinations > so that the routing decision can be based on the identity of > the group." > REFERENCE > "draft-ietf-iptel-trip-07.txt, J. Rosenberg et al, > section 5.9." again be aware of the pitfalls of referencing drafts. -09 is the current draft i think, so this info is essentially stale already. [DZ] agree. > ::= { tripMIBObjects 2 } > > tripSupportedCommunityEntry OBJECT-TYPE > SYNTAX TripSupportedCommunityEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Entry containing information a community. A TRIP say "... information about a community." [DZ] Done. > community is a group of destinations that share some > common property." typically, what's that "common property" the destination share? [DZ] I have made the description more descriptive. > INDEX { applIndex, tripSupportedCommunityId } > ::= { tripSupportedCommunityTable 1 } > > TripSupportedCommunityEntry ::= SEQUENCE { > tripSupportedCommunityId TripItad, > tripSupportedCommunityItad TripItad, > tripSupportedCommunityRowStatus RowStatus > } > > tripSupportedCommunityId OBJECT-TYPE > SYNTAX TripItad > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The identifier of the supported Community." > ::= { tripSupportedCommunityEntry 1 } > > tripSupportedCommunityItad OBJECT-TYPE > SYNTAX TripItad > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The Itad of the community." i'm not clear on what the differences is between the tripSupportedCommunityId (index object) and this tripSupportedCommunityItad?? [DZ] please see section "5.9.1. Syntax of Communities" in the TRIP spec. > ::= { tripSupportedCommunityEntry 2 } > > tripSupportedCommunityRowStatus OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The row status of the entry. This object is required to > create or delete rows." what is the criteria for row creation? is the tripSupportedCommunityItad a required object to create a row - seems a default Itad wouldn't be likely. do you createAndGo or do you need to create the row and then transition it to active w/ an additional set operation? things like that help implementors out tremeduously. [DZ] I will try to make this more descriptive. > ::= { tripSupportedCommunityEntry 3 } > > -- > -- TripPeerTable > -- > tripPeerTable OBJECT-TYPE > SYNTAX SEQUENCE OF TripPeerEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The TRIP peer table. This table contains one entry per > TRIP peer, and information about the connection with > the peer." so now this table seems to be info related to trip entities no in this system, which reinforces my issues of ambiguity in the earlier tripCfgTable (references to local and peer). [DZ] See above > ::= { tripMIBObjects 4 } > > tripPeerEntry OBJECT-TYPE > SYNTAX TripPeerEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Entry containing information about the connection with > a TRIP peer." > INDEX { applIndex, > tripPeerRemoteAddrInetType, > tripPeerRemoteAddr } why use the peers address objects for indexing instead of just tripPeerIdentifier? isn't tripPeerIdentifier unique? [DZ] the tripPeerIdentifier is distinct, but I believe it is easier to identify a peer from its inet address. > ::= {tripPeerTable 1} > > TripPeerEntry ::= SEQUENCE { > tripPeerRemoteAddrInetType InetAddressType, > tripPeerRemoteAddr InetAddress, > tripPeerIdentifier TripId, > tripPeerState INTEGER, > tripPeerAdminStatus INTEGER, > tripPeerNegotiatedVersion Integer32, > tripPeerSendReceiveMode INTEGER, > tripPeerRemotePort Integer32, > tripPeerRemoteItad TripItad, > tripPeerConnectRetryInterval Integer32, > tripPeerMaxRetryInterval Integer32, > tripPeerHoldTime Integer32, > tripPeerKeepAlive Integer32, > tripPeerHoldTimeConfigured Integer32, > tripPeerKeepAliveConfigured Integer32, > tripPeerMinItadOriginationInterval Integer32, > tripPeerMinRouteAdvertisementInterval Integer32, > tripPeerMaxPurgeTime Integer32, > tripPeerDisableTime Integer32, > tripPeerRowStatus RowStatus > } > > tripPeerRemoteAddrInetType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The type of Inet Address of the tripPeerRemoteAddr." > REFERENCE > "RFC 2851, section 3." > ::= { tripPeerEntry 1 } > > tripPeerRemoteAddr OBJECT-TYPE > SYNTAX InetAddress (SIZE(0..125)) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The remote IP address of this entry's TRIP peer. The > size value of 125 has been assigned due to the sub > identifier of object types length limitation as > defined in SMIv2." i don't understand this last sentence. is it something about InetAddress?? was the same not relevant for tripLocalAddr?? [DZ] The longest possible index length for an SNMP v2 entry is 128. The applIndex takes one, the tripPeerRemoteAddrInetType takes one, leaving 126. 125 seems reasonable. > REFERENCE > "RFC 2851, section 3." > ::= { tripPeerEntry 2 } > > tripPeerIdentifier OBJECT-TYPE > SYNTAX TripId > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "TRIP identifier of this entry's TRIP peer." what does it mean to be "this entry's TRIP peer"?? the peer is not a peer of this mib table entry but rather a peer of the local TRIP LS, right? [DZ] agreed. > ::= { tripPeerEntry 3 } > > tripPeerState OBJECT-TYPE > SYNTAX INTEGER { > idle(1), > connect(2), > active(3), > openSent(4), > openConfirm(5), > established(6) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "TRIP Peer Finite State Machine state. > > idle(1) : The initial state. Local LS refuses all > incoming connections. No resources are > allocated to the peer. > > connect(2) : Local LS waiting for a transport protocol > connection to be completed to the peer, and > is listening for inbound transport > connections from the peer. > > active(3) : LS is listening for an inbound connection > from the peer, but is not in the process of > initiating a connection to the peer. > > openSent(4) : LS has sent an OPEN message to its peer and > is waiting for an OPEN message from its > peer. > > openConfirm(5): LS has sent an OPEN to its peer, received an > OPEN from its peer, and sent a KEEPALIVE in > response to the OPEN. The LS is now waiting > for a KEEPALIVE or NOTIFICATION message in > response to its OPEN. > > established(6): LS can exchange UPDATE, NOTIFICATION,and > KEEPALIVE messages with its peer." > ::= { tripPeerEntry 4 } > > tripPeerAdminStatus OBJECT-TYPE > SYNTAX INTEGER { > up(1), > down(2) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The desired TRIP connection state." how might setting this to "up" affect tripPeerState? would tripPeerState connect->openSent->openConfirm->established? if there is any relationship, you may want to describe it. i may be offbase in presuming there is some relationship. [DZ] I will look into this further. > ::= { tripPeerEntry 5 } > > tripPeerNegotiatedVersion OBJECT-TYPE > SYNTAX Integer32 (1..255) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The negotiated version of TRIP running between this > local entity and this peer." > ::= { tripPeerEntry 6 } this is the second object reflecting trip protocol version. consider creating a TC TripProtocolVersion. [DZ] done. > > tripPeerSendReceiveMode OBJECT-TYPE > SYNTAX INTEGER { > sendReceive(1), > sendOnly(2), > receiveOnly(3) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The operational mode of this peer." this is the same syntax as tripSendRecieveMode. again, a good candidate for making this syntax a TC TripSendRecvMode. [DZ] done. > ::= { tripPeerEntry 7 } > > tripPeerRemotePort OBJECT-TYPE > SYNTAX Integer32 (1..65535) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The remote port for the TCP connection between the > TRIP peers." here you are explicit about this being a tcp port. does that answer my question regarding tripLocalPort? [DZ] Yes > ::= { tripPeerEntry 8 } > > tripPeerRemoteItad OBJECT-TYPE > SYNTAX TripItad > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The Internet Telephony Administrative domain of > this peer." > ::= { tripPeerEntry 9 } > > tripPeerConnectRetryInterval OBJECT-TYPE > SYNTAX Integer32 (0..2147483647) same comment as before on possibly using SNMPv2-TC TimeInterval. > UNITS "Seconds" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Specifies the initial amount of time that will elapse > between connection retry. This value should double > after each attempt up to the value of > tripPeerMaxRetryInterval." therefore, the value of this object has a dependency on the value of tripPeerMaxRetryInterval. this objects value must always be <= tripPeerMaxRetryInterval. attempts to set it higher than the max retry should not be allowed, right? [DZ] I will make it clearer. > DEFVAL { 120 } > ::= { tripPeerEntry 10 } > > tripPeerMaxRetryInterval OBJECT-TYPE > SYNTAX Integer32 (0..2147483647) same comment as before on possibly using SNMPv2-TC TimeInterval > UNITS "Seconds" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Specifies the maximum amount of time that will elapse > between connection retries." somehow refer back to the relationship between this object and tripPeerConnectRetryInterval. what if there's an attempt to set this object to be less than tripPeerConnectRetryInterval? it should fail, right? [DZ] Agreed > DEFVAL { 360 } > ::= { tripPeerEntry 11 } > > tripPeerHoldTime OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) same comment as before on possibly using SNMPv2-TC TimeInterval > UNITS "Seconds" > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The time interval in seconds for the hold timer that > is established with the peer. The value of this object > is the smaller of the values in > tripPeerHoldTimeConfigured and the hold time received > in the open message." > ::= { tripPeerEntry 12 } > > tripPeerKeepAlive OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) same comment as before on possibly using SNMPv2-TC TimeInterval > UNITS "Seconds" > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Specifies the amount of time that must elapse between > keep alive messages." > ::= { tripPeerEntry 13 } > > tripPeerHoldTimeConfigured OBJECT-TYPE > SYNTAX Integer32 (0 | 3..65535) same comment as before on possibly using SNMPv2-TC TimeInterval > UNITS "Seconds" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Specifies the maximum time that may elapse between the > receipt of successive keepalive or update message." > DEFVAL { 240 } > ::= { tripPeerEntry 14 } > > tripPeerKeepAliveConfigured OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) same comment as before on possibly using SNMPv2-TC TimeInterval > UNITS "Seconds" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Specifies the amount of time that must elapse between > keep alive messages." > DEFVAL { 30 } > ::= { tripPeerEntry 15 } > > tripPeerMinItadOriginationInterval OBJECT-TYPE > SYNTAX Integer32 (0..2147483647) same comment as before on possibly using SNMPv2-TC TimeInterval > UNITS "Seconds" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Amount of time that must elapse between advertisement > of update message that report changes within the Location message -> messages [DZ] ok > Server's own ITAD." > DEFVAL { 30 } > ::= { tripPeerEntry 16 } > > tripPeerMinRouteAdvertisementInterval OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) same comment as before on possibly using SNMPv2-TC TimeInterval > UNITS "Seconds" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Specifies minimal interval between successive > advertisement to a particular destination from an LS." > DEFVAL { 30 } > ::= { tripPeerEntry 17 } > > tripPeerMaxPurgeTime OBJECT-TYPE > SYNTAX Integer32 (1..65535) same comment as before on possibly using SNMPv2-TC TimeInterval > UNITS "Seconds" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Indicate the interval that the location server must either say "location server" or "LS" throughout the mib, but don't keep switching back and forth. i've noticed this happening. [DZ] Changed all to LS. > maintain routes marked as withdrawn in its database." > DEFVAL { 10 } > ::= { tripPeerEntry 18 } > > tripPeerDisableTime OBJECT-TYPE > SYNTAX Integer32 (1..65535) same comment as before on possibly using SNMPv2-TC TimeInterval > UNITS "Seconds" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Indicate the interval that the TRIP module of the the peer LS presumably? > location server must be disabled while routes > originated by this location server with high sequence is "this" referring to the local ls or the peer ls. [DZ] Fixed > numbers can be removed." > DEFVAL { 180 } > ::= { tripPeerEntry 19 } > > tripPeerRowStatus OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This object is used to create and delete rows in the > tripPeerTable." again, row creation criteria should be added to aid implementors and nm appl developers. > ::= { tripPeerEntry 20 } > > -- > -- tripPeerRouteTypeTable > -- > tripPeerRouteTypeTable OBJECT-TYPE > SYNTAX SEQUENCE OF TripPeerRouteTypeEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The TRIP peer Route Type table. This table contains one > entry per supported protocol - address family pair." > ::= { tripMIBObjects 5 } > > tripPeerRouteTypeEntry OBJECT-TYPE > SYNTAX TripPeerRouteTypeEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Entry containing information about the route type that > the TRIP peer supports." > INDEX { applIndex, > tripPeerRemoteAddrInetType, > tripPeerRemoteAddr, if tripPeerIdentifier is viable, use it instead of address objects. > tripPeerRtTypeProtocolId, > tripPeerRtTypeAddrFamilyId } why do these need to be part of the index?? they are oids themselves. your index into this table, just to retrieve the value of the RowStatus object could be very large and cumbersome. why aren't the protoclid and addrfamily oids the data retrieved from this table as object values rather than index components? [DZ] Both these fields make the entry unique, therefore, both are needed in the index. > ::= { tripPeerRouteTypeTable 1 } > > TripPeerRouteTypeEntry ::= SEQUENCE { > tripPeerRtTypeProtocolId TripAppProtocol, > tripPeerRtTypeAddrFamilyId TripAddressFamily, > tripPeerRtTypeRowStatus RowStatus > } > > tripPeerRtTypeProtocolId OBJECT-TYPE > SYNTAX TripAppProtocol > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The object identifier of a protocol that this peer is > using." > ::= { tripPeerRouteTypeEntry 1 } > > tripPeerRtTypeAddrFamilyId OBJECT-TYPE > SYNTAX TripAddressFamily > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The object identifier of an address family that this peer > belongs to." > ::= { tripPeerRouteTypeEntry 2 } > > tripPeerRtTypeRowStatus OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object is used to instantiate a row in this table. > The normal row status values of createAndGo(4), > createAndWait(5) and delete(6) have no application in this > table." good, some beginnings of the row creation criteria that i have been mentioning. now why not applicable here? if i can't do createAndGo or createAndWait then how do i create a row in this table? are these rows instantiated via trip and not by a nms?? i'm confused. [DZ] The row status object is used only to instantiate the row in the table. If the two index objects could be made read-only instead of not accessible, then the row status would not be needed. > ::= { tripPeerRouteTypeEntry 3 } > > -- > -- TripPeerStatsTable > -- > tripPeerStatsTable OBJECT-TYPE > SYNTAX SEQUENCE OF TripPeerStatsEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The TRIP peer stats table. This table contains one entry > per TRIP peer, and statistics related to the connection > with the peer." > ::= { tripMIBObjects 6 } > > tripPeerStatsEntry OBJECT-TYPE > SYNTAX TripPeerStatsEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Entry containing information about the connection with > a TRIP peer." > AUGMENTS { tripPeerEntry } > ::= { tripPeerStatsTable 1 } > > TripPeerStatsEntry ::= SEQUENCE { > tripPeerInUpdates Counter32, > tripPeerOutUpdates Counter32, > tripPeerInTotalMessages Counter32, > tripPeerOutTotalMessages Counter32, > tripPeerFsmEstablishedTransitions Counter32, > tripPeerFsmEstablishedTime DateAndTime, > tripPeerInUpdateElapsedTime Gauge32 > } > > tripPeerInUpdates OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of TRIP update messages received from this > peer since the last restart of this location server." > ::= { tripPeerStatsEntry 1 } > > tripPeerOutUpdates OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of TRIP update messages transmitted to transmitted -> sent.... consistent w/ other parts of the mib using send/receive terminology. i know.... a real nit! ;) [DZ] ok. > this peer since the last restart of this location > server." > ::= { tripPeerStatsEntry 2 } > > tripPeerInTotalMessages OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The total number of TRIP messages received to the to -> from [DZ] ok. > remote peer on this connection since the last restart > of this location server." > ::= { tripPeerStatsEntry 3 } > > tripPeerOutTotalMessages OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The total number of outgoing TRIP messages sent since for consistency sake... say "...sent to the remote peer since...." [DZ] ok. > the last restart of this location server." > ::= { tripPeerStatsEntry 4 } > > tripPeerFsmEstablishedTransitions OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of times the TRIP peer has transitioned into > the established state since the last restart of this > location server." > ::= { tripPeerStatsEntry 5 } > > tripPeerFsmEstablishedTime OBJECT-TYPE > SYNTAX DateAndTime > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Indicates how long in seconds this peer has been in the > established state." description doesn't match up w/ the syntax. DateAndTime is more than just seconds. [DZ] agreed. > ::= { tripPeerStatsEntry 6 } > > tripPeerInUpdateElapsedTime OBJECT-TYPE > SYNTAX Gauge32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Elapsed time in seconds since the last TRIP update > message was received from the peer." not sure why Gauge32 is used here. again, why not TimeInterval. description would have to not refer to seconds. [DZ] I agree that a gauge might not be the best thing to use here. I think this is an appropriate place to use TimeInterval. i have to stop here. i will send more comments on the remainder of the mib early next week. kevin > ::= { tripPeerStatsEntry 7 } > > -- TRIP Received Route Table. This table contains > -- all routes from all sources. Each entry consists > -- of a route and its associated path attributes. > > tripRouteTable OBJECT-TYPE > SYNTAX SEQUENCE OF TripRouteEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The TRIP route table containing information about > reachable routes that are to be added to service by the > receiving LS." > ::= { tripMIBObjects 7 } > > tripRouteEntry OBJECT-TYPE > SYNTAX TripRouteEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Information about a route to a called destination." > INDEX { applIndex, > tripRouteAppProtocol, > tripRouteAddressFamily, > tripRouteAddress, > tripRoutePeer > } > ::= { tripRouteTable 1 } > > TripRouteEntry ::= SEQUENCE { > tripRouteAppProtocol TripAppProtocol, > tripRouteAddressFamily TripAddressFamily, > tripRouteAddress OCTET STRING, > tripRoutePeer TripId, > tripRouteAddressSequenceNumber Integer32, > tripRouteAddressOriginatorId TripItad, > tripRouteNextHopServerIAddrType InetAddressType, > tripRouteNextHopServer InetAddress, > tripRouteNextHopServerPort Integer32, > tripRouteNextHopServerItad TripItad, > tripRouteMultiExitDisc Unsigned32, > tripRouteLocalPref Unsigned32, > tripRouteAdvertisementPath OCTET STRING, > tripRouteRoutedPath OCTET STRING, > tripRouteAtomicAggregate TruthValue, > tripRouteBest TruthValue, > tripRouteUnknown OCTET STRING, > tripRouteWithdrawn TruthValue, > tripRouteConverted TruthValue > } > > tripRouteAppProtocol OBJECT-TYPE > SYNTAX TripAppProtocol > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The protocol for which this routing table is > maintained." > ::= { tripRouteEntry 1 } > > tripRouteAddressFamily OBJECT-TYPE > SYNTAX TripAddressFamily > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Specifies the type of address for the destination > route." > ::= { tripRouteEntry 2 } > > tripRouteAddress OBJECT-TYPE > SYNTAX OCTET STRING (SIZE(1..32)) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This is an address (prefix) of the family type given by > Address Family of the destination." > ::= { tripRouteEntry 3 } > > tripRoutePeer OBJECT-TYPE > SYNTAX TripId > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The identifier of the peer where the route information > was learned." > ::= { tripRouteEntry 4 } > > tripRouteAddressSequenceNumber OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Indicates the version of the destination route > originated by the location server identified by > tripRouteAddressOriginatorId intra-domain > attribute." > ::= { tripRouteEntry 5 } > > tripRouteAddressOriginatorId OBJECT-TYPE > SYNTAX TripItad > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This is an intra-domain attribute indicating the > internal location server that originated the route > into the ITAD." > ::= { tripRouteEntry 6 } > > tripRouteNextHopServerIAddrType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The type of Inet Address of the tripRouteNextHopServer." > REFERENCE > "RFC 2851, section 3." > ::= { tripRouteEntry 7 } > > tripRouteNextHopServer OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Indicates the next hop that messages of a given > protocol destined for tripRouteAddress should > be sent to." > ::= { tripRouteEntry 8 } > > tripRouteNextHopServerPort OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The port of the next hop server that this route > will use." > ::= { tripRouteEntry 9 } > > tripRouteNextHopServerItad OBJECT-TYPE > SYNTAX TripItad > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Indicates the domain of the next hop." > ::= { tripRouteEntry 10 } > > tripRouteMultiExitDisc OBJECT-TYPE > SYNTAX Unsigned32 (0..4294967295) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "When two ITADs are connected by more than one set of peers, > it is used to descriminate between multiple exit points to > an adjacent ITAD." > ::= { tripRouteEntry 11 } > > tripRouteLocalPref OBJECT-TYPE > SYNTAX Unsigned32 (0..4294967295) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Indicated the local LS's degree of preference for an > advertised route destination." > ::= { tripRouteEntry 12 } > > tripRouteAdvertisementPath OBJECT-TYPE > SYNTAX OCTET STRING (SIZE(4..252)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Identifies the ITADs through wich routing information > carried in an advertisement has passed. > > This object is probably best represented as sequence of > integer. For SMI compatibility, though, it is represented > as OCTET STRING. This object is a sequence of ITADs in > network byte order." > ::= { tripRouteEntry 13 } > > tripRouteRoutedPath OBJECT-TYPE > SYNTAX OCTET STRING (SIZE(4..252)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Identifies the ITADs through which messages sent using > this route would pass. These are as subset of > tripRouteAdvertisementPath. > > This object is probably best represented as sequence of > integer. For SMI compatibility, though, it is represented > as OCTET STRING. This object is a sequence of ITADs in > network byte order." > ::= { tripRouteEntry 14 } > > tripRouteAtomicAggregate OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Indicates that a route may traverse domains not listed in > tripRouteRoutedPath. If an LS selects the less specific > route from a set of overlapping routes, then this value > returns TRUE." > ::= { tripRouteEntry 15 } > > tripRouteBest OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "An indication of whether this route was chosen as the > best TRIP route." > ::= { tripRouteEntry 16 } > > tripRouteUnknown OBJECT-TYPE > SYNTAX OCTET STRING (SIZE(0..255)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "One or more attributes not understood by this location > server." > ::= { tripRouteEntry 17 } > > tripRouteWithdrawn OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Indicates if this route is to be removed from service by > the receiving LS." > ::= { tripRouteEntry 18 } > > tripRouteConverted OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Indicates if this route has been converted to a > different application protocol than it had originally." > ::= { tripRouteEntry 19 } > > -- > -- TRIP Received Route CommunityTable. > -- > > tripRouteCommunityTable OBJECT-TYPE > SYNTAX SEQUENCE OF TripRouteCommunityEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table containing a list of TRIP communities associated > with a route." > REFERENCE > "draft-ietf-iptel-trip-07.txt, J. Rosenberg et al, > section 5.9." > ::= { tripMIBObjects 8 } > > tripRouteCommunityEntry OBJECT-TYPE > SYNTAX TripRouteCommunityEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Information about communities associated with a route. An > entry with a tripRouteAddress of 00 and a tripRoutePeer of > 0 refers to the local LS." > INDEX { applIndex, > tripRouteAppProtocol, > tripRouteAddressFamily, > tripRouteAddress, > tripRoutePeer, > tripRouteCommunityId > } > ::= { tripRouteCommunityTable 1 } > > TripRouteCommunityEntry ::= SEQUENCE { > tripRouteCommunityId TripItad, > tripRouteCommunityItad TripItad > } > > tripRouteCommunityId OBJECT-TYPE > SYNTAX TripItad > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The community identifier." > ::= { tripRouteCommunityEntry 1 } > > tripRouteCommunityItad OBJECT-TYPE > SYNTAX TripItad > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The ITAD associated with this community." > ::= { tripRouteCommunityEntry 2 } > > -- > -- tripItadTopologyTable > -- > > tripItadTopologyTable OBJECT-TYPE > SYNTAX SEQUENCE OF TripItadTopologyEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The sequence of link connections between peers within > an ITAD." > ::= { tripMIBObjects 9 } > > tripItadTopologyEntry OBJECT-TYPE > SYNTAX TripItadTopologyEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Information about a peer of the location server identified > by tripOriginatorIdentifier." > INDEX { applIndex, tripItadTopologyOrigId } > ::= { tripItadTopologyTable 1 } > > TripItadTopologyEntry ::= SEQUENCE { > tripItadTopologyOrigId TripItad, > tripItadTopologySeqNum Integer32 > } > > tripItadTopologyOrigId OBJECT-TYPE > SYNTAX TripItad > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Indicates the internal location server that originated > the ITAD topology information into the ITAD." > ::= { tripItadTopologyEntry 1 } > > tripItadTopologySeqNum OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Indicates the version of the ITAD topology > originated by the location server identified by > tripOriginatorIdentifier." > ::= { tripItadTopologyEntry 2 } > > -- > -- tripItadTopologyIdTable > -- > > tripItadTopologyIdTable OBJECT-TYPE > SYNTAX SEQUENCE OF TripItadTopologyIdEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The list of other location servers within the ITAD > domain that the location server identified by > tripOriginatorIdentifier is currently peering." > ::= { tripMIBObjects 10 } > > tripItadTopologyIdEntry OBJECT-TYPE > SYNTAX TripItadTopologyIdEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Information about a peer to the location server > identified by tripOriginatorIdentifier." > INDEX { applIndex, > tripItadTopologyOrigId, > tripItadTopologyId } > ::= { tripItadTopologyIdTable 1 } > > TripItadTopologyIdEntry ::= SEQUENCE { > tripItadTopologyId TripId, > tripItadTopologyIdRowStatus RowStatus > } > > tripItadTopologyId OBJECT-TYPE > SYNTAX TripId > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The index into this entry. Indicates the other location > servers within the ITAD domain that this location server > identified by tripOriginatorIdentifier is currently > peering." > ::= { tripItadTopologyIdEntry 1 } > > tripItadTopologyIdRowStatus OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object is used to instantiate a row in this table. > The normal row status values of createAndGo(4), > createAndWait(5) and delete(6) have no application in this > table." > ::= { tripItadTopologyIdEntry 2 } > > -- > -- Notification objects > -- > > tripNotifApplIndex OBJECT-TYPE > SYNTAX INTEGER (1..2147483647) > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "This object contains the applIndex as described > in RFC 2788. It is used to bind this notification > with a specific instance of TRIP entity." > ::= { tripMIBNotifications 1 } > > tripNotifPeerAddrInetType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "The type of Inet Address of the tripNotifPeerAddr." > REFERENCE > "RFC 2851, section 3." > ::= { tripMIBNotifications 2 } > > tripNotifPeerAddr OBJECT-TYPE > SYNTAX InetAddress (SIZE(0..125)) > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "The remote IP address of this entry's TRIP peer. The > size value of 125 has been assigned due to the sub > identifier of object types length limitation as > defined in SMIv2." > REFERENCE > "RFC 2851, section 3." > ::= { tripMIBNotifications 3 } > > tripNotifPeerErrCode OBJECT-TYPE > SYNTAX INTEGER { > messageHeader(1), > openMessage(2), > updateMessage(3), > holdTimerExpired(4), > finiteStateMachine(5), > cease(6), > tripNotification(7) > } > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "Notification message of TRIP error. The meaning of this > value is applicable to the following functions: > > 1 - message header. > All errors detected while processing the TRIP message > header. > 2 - open message. > All errors detected while processing the OPEN message. > 3 - update message. > All errors detected while processing the UPDATE message. > 4 - hold timer expired. > A notification generated when the hold timer expires. > 5 - finite state machine. > All errors detected by the TRIP Finite State Machine. > 6 - cease. > Any fatal error condition that the rest of the values > do not cover. > 7 - trip notification message. > Any error encountered while sending a notification > message." > ::= { tripMIBNotifications 4 } > > tripNotifPeerErrSubcode OBJECT-TYPE > SYNTAX Integer32 (1..7) > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "The sub error code associated with error code. The meaning > of this value is dependent on the value of > tripNotifPeerErrCode. > > Message Header (1) Error Subcodes: > 1 - Bad Message Length. > 2 - Bad Message Type. > > OPEN Message (2) Error Subcodes: > 1 - Unsupported Version Number. > 2 - Bad Peer ITAD. > 3 - Bad TRIP Identifier. > 4 - Unsupported Optional Parameter. > 5 - Unacceptable Hold Time. > 6 - Unsupported Capability. > 7 - Capability Mismatch. > > UPDATE Message (3) Error Subcodes: > 1 - Malformed Attribute List. > 2 - Unrecognized Well-known Attribute. > 3 - Missing Well-known Mandatory Attribute. > 4 - Attribute Flags Error. > 5 - Attribute Length Error. > 6 - Invalid Attribute." > ::= { tripMIBNotifications 5 } > > -- > -- Notifications > -- > tripEstablished NOTIFICATION-TYPE > STATUS current > DESCRIPTION > "The TRIP Established event is generated when the TRIP > FSM enters the ESTABLISHED state." > ::= { tripMIBNotifications 6 } > > tripFSM NOTIFICATION-TYPE > OBJECTS { tripNotifApplIndex, > tripNotifPeerAddrInetType, > tripNotifPeerAddr, > tripNotifPeerErrCode, > tripNotifPeerErrSubcode, > tripPeerState > } > STATUS current > DESCRIPTION > "The trip FSM Event is generated when any error is detected > by the TRIP Finite State Machine." > ::= { tripMIBNotifications 7 } > > tripOpenMessageError NOTIFICATION-TYPE > OBJECTS { tripNotifApplIndex, > tripNotifPeerAddrInetType, > tripNotifPeerAddr, > tripNotifPeerErrCode, > tripNotifPeerErrSubcode, > tripPeerState > } > STATUS current > DESCRIPTION > "Errors detected while processing the OPEN message." > ::= { tripMIBNotifications 8 } > > tripUpdateMessageError NOTIFICATION-TYPE > OBJECTS { tripNotifApplIndex, > tripNotifPeerAddrInetType, > tripNotifPeerAddr, > tripNotifPeerErrCode, > tripNotifPeerErrSubcode, > tripPeerState > } > STATUS current > DESCRIPTION > "Errors detected while processing the UPDATE message." > ::= { tripMIBNotifications 9 } > > tripHoldTimerExpired NOTIFICATION-TYPE > OBJECTS { tripNotifApplIndex, > tripNotifPeerAddrInetType, > tripNotifPeerAddr, > tripNotifPeerErrCode, > tripNotifPeerErrSubcode, > tripPeerState > } > STATUS current > DESCRIPTION > "The system does not receive successive messages within the > period specified by the negotiated Hold Time." > ::= { tripMIBNotifications 10 } > > tripConnectionCollision NOTIFICATION-TYPE > OBJECTS { tripNotifApplIndex } > STATUS current > DESCRIPTION > "A pair of LSs tried to simultaneously to establish a > transport connection to each other." > ::= { tripMIBNotifications 11 } > > tripNotificationErr NOTIFICATION-TYPE > OBJECTS { tripNotifApplIndex } > STATUS current > DESCRIPTION > "Generated if there is an error detected in a TRIP > notification message sent with another cause. Note that > the TRIP notification refered to in this object is not > an SNMP notification, it is a specific message described > in the TRIP specification." > REFERENCE > "draft-ietf-iptel-trip-07.txt, J. Rosenberg et al, > section 6.4." > ::= { tripMIBNotifications 12 } > > -- > -- Compliance Statements > -- > tripCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "The compliance statement for TRIP entities." > > MODULE -- this module > MANDATORY-GROUPS { tripConfigGroup, > tripPeerTableConfigGroup, > tripRouteGroup, > tripItadTopologyGroup, > tripPeerTableStatsGroup } > > GROUP tripNotificationGroup > DESCRIPTION > "This group is optional. A TRIP entity can choose not to > send any notifications. If this group is implemented, the > tripNotifObjectGroup must also be implemented." > > GROUP tripNotifObjectGroup > DESCRIPTION > "This group is optional. A TRIP entity can choose not to > send any notifications. If this group is implemented, the > tripNotificationGroup must also be implemented." > > MODULE NETWORK-SERVICES-MIB > MANDATORY-GROUPS { applRFC1565Group } > > ::= { tripMIBCompliance 1 } > > -- > -- Object and event conformance groups > -- > > tripConfigGroup OBJECT-GROUP > OBJECTS { > tripProtocolVersion, > tripLocalItad, > tripIdentifier, > tripOperStatus, > tripAdminStatus, > tripLocalAddrIAddrType, > tripLocalAddr, > tripLocalPort, > tripMinItadOriginationInterval, > tripMinRouteAdvertisementInterval, > tripMaxPurgeTime, > tripDisableTime, > tripSendReceiveMode, > tripSupportedCommunityItad, > tripSupportedCommunityRowStatus > } > STATUS current > DESCRIPTION > "The global objects for configuring trip." > ::= { tripMIBGroups 1 } > > tripPeerTableConfigGroup OBJECT-GROUP > OBJECTS { > tripPeerIdentifier, > tripPeerState, > tripPeerAdminStatus, > tripPeerNegotiatedVersion, > tripPeerSendReceiveMode, > tripPeerRemotePort, > tripPeerRemoteItad, > tripPeerConnectRetryInterval, > tripPeerMaxRetryInterval, > tripPeerHoldTime, > tripPeerKeepAlive, > tripPeerHoldTimeConfigured, > tripPeerKeepAliveConfigured, > tripPeerMinItadOriginationInterval, > tripPeerMinRouteAdvertisementInterval, > tripPeerMaxPurgeTime, > tripPeerDisableTime, > tripPeerRowStatus > } > > STATUS current > DESCRIPTION > "The global objects for configuring the TRIP peer table." > ::= { tripMIBGroups 2 } > > tripPeerTableStatsGroup OBJECT-GROUP > OBJECTS { > tripPeerInUpdates, > tripPeerOutUpdates, > tripPeerInTotalMessages, > tripPeerOutTotalMessages, > tripPeerFsmEstablishedTransitions, > tripPeerFsmEstablishedTime, > tripPeerInUpdateElapsedTime > } > > STATUS current > DESCRIPTION > "The global statistics the TRIP peer table." > ::= { tripMIBGroups 3 } > > tripRouteGroup OBJECT-GROUP > OBJECTS { > tripRouteAddressSequenceNumber, > tripRouteAddressOriginatorId, > tripRouteNextHopServerIAddrType, > tripRouteNextHopServer, > tripRouteNextHopServerPort, > tripRouteNextHopServerItad, > tripRouteMultiExitDisc, > tripRouteLocalPref, > tripRouteAdvertisementPath, > tripRouteRoutedPath, > tripRouteAtomicAggregate, > tripRouteBest, > tripRouteUnknown, > tripRouteWithdrawn, > tripRouteConverted, > tripRouteCommunityItad, > tripPeerRtTypeRowStatus > } > > STATUS current > DESCRIPTION > "The global objects for configuring route attribute." > ::= { tripMIBGroups 4 } > > tripItadTopologyGroup OBJECT-GROUP > OBJECTS { > tripItadTopologySeqNum, > tripItadTopologyIdRowStatus > } > STATUS current > DESCRIPTION > "The objects that define the TRIP ITAD topology." > ::= { tripMIBGroups 5 } > > tripNotificationGroup NOTIFICATION-GROUP > NOTIFICATIONS { > tripEstablished, > tripFSM, > tripOpenMessageError, > tripUpdateMessageError, > tripHoldTimerExpired, > tripConnectionCollision, > tripNotificationErr > } > STATUS current > DESCRIPTION > "A collection of notifications defined for TRIP." > ::= { tripMIBGroups 6 } > > tripNotifObjectGroup OBJECT-GROUP > OBJECTS { > tripNotifApplIndex, > tripNotifPeerAddrInetType, > tripNotifPeerAddr, > tripNotifPeerErrCode, > tripNotifPeerErrSubcode > } > STATUS current > DESCRIPTION > "The collection of objects that specify information for > TRIP notifications." > ::= { tripMIBGroups 7 } > > END -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police/ Sometimes I think I understand everything, then I regain consciousness. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel ------_=_NextPart_001_01C14DC9.7240253A Content-Type: text/html; charset="iso-8859-1"
Kevin,
Thanks for you detailed comments!
 
Responses inline.
 
Cheers,
DZ

-----Original Message-----
From: Kevin Lingle [mailto:klingle@cisco.com]
Sent: Friday, August 31, 2001 11:42 AM
To: iptel@lists.bell-labs.com
Subject: RE: [Fwd: [Fwd: [IPTEL] FW:
I-DACTION:draft-ietf-iptel-trip-mib-0 0.txt]]


hi,

i have some comments on the trip mib.  i'm not a trip expert, so
consider most comments from a general snmp/mib perspective.

my comments are embedded below.

this is only a partial review.  i made it up to tripRouteTable.
i'll send more comments early next week.

the above wg information is nice, but i think you should
list it outside the mib module (elsewhere in the draft doc)
since it is subject to change.

the list of co-authors is presumed to be more stable, so
it's good to keep in the mib.

[DZ] Done.

>
>     Mailing List
>     ============
>     iptel-admin@lists.bell-labs.com
>
>     General information about the mailing list is at:
>       http://lists.bell-labs.com/mailman/listinfo/iptel/
>
>     Archives:
>       http://lists.bell-labs.com/pipermail/iptel/"

same basic comment about this maillist section.  although
you should provide one "Email" contact other than the
authors.  the iptel list might be a good common list for
trip mib discussion or create your own trip-mib list.


for sip mib work, we used yahoogroups.com, but now as we
get into last call, the comments have been that ietf
frowns on such list servers and we are using the general
discussion list for sip.  

try and pick a list that will be available longterm and salient
to trip or specific to the trip-mib.  that way it won't
need to be changed repeatedly in the mib... a task that will
be harder once this is an rfc.

[DZ] We discussed the need for a separate list last December but
it was decided that it was not necessary.

>
> DESCRIPTION
>    "The MIB module describing Telephony Routing
>     over IP (TRIP)"

i think you should add some more description here
of what trip is and does.

[DZ] I agree.

> REVISION      "200102260000Z"
> DESCRIPTION
>     "The initial revision of this MIB module was
>     published as draft-zinman-trip-mib-00.txt."

remove this reference to a old draft.  it will be of
no use shortly and certainly no down the road in a
year or two.

just make this revision "The initial version of this MIB..."

[DZ] Done.

> ::= { mib-2 } -- to be assigned by IANA
>
> --
> -- Textual Conventions
> --
> TripItad ::= TEXTUAL-CONVENTION
>     STATUS current
>     DESCRIPTION
>        "The values for identifying the IP Telephony
>        Administrative Domain."

add "(ITAD)" to formally introduce the acryonym.

[DZ] Done.

>     SYNTAX Unsigned32 (0..4294967295)
>
> TripId ::= TEXTUAL-CONVENTION
>     STATUS current
>     DESCRIPTION
>        "The range of legal values for a TRIP Identifier."

say some more about what a trip identifier is and is used for.

[DZ] Agree.

>     SYNTAX Unsigned32 (0..4294967295)
>
> TripAppProtocol ::= TEXTUAL-CONVENTION
>     STATUS current
>     DESCRIPTION
>         "The application protocol used for communication with
>         TRIP LS's. Protocol defined in this document are:

what's an "LS" - expand acryonmym on first use.

[DZ] Done.

>             tripSupProtSIP
>             tripSupProtH323Q931
>             tripSupProtH323RAS
>             tripSupProtH323ANNEXG.
>
>         Users can add their own application protocol types by defining
>         a TripAppProtocol type in a private specification."
>     SYNTAX OBJECT IDENTIFIER
>
> TripAddressFamily ::= TEXTUAL-CONVENTION
>     STATUS current
>     DESCRIPTION
>         "A type of address for a TRIP route. Address families defined
>         within this document are:

change "document" to "MIB module".

[DZ]Done.

>             tripAddrFamilyDecimal
>             tripAddrFamilyPentadecimal
>             tripAddrFamilyE164.
>
>        Users can add their own address family types by defining a
>        TripAddressFamily type in a private specification."
>     SYNTAX OBJECT IDENTIFIER
>
>     tripMIBNotifications OBJECT IDENTIFIER ::= { tripMIB 0 }
>     tripMIBObjects       OBJECT IDENTIFIER ::= { tripMIB 1 }
>     tripMIBConformance   OBJECT IDENTIFIER ::= { tripMIB 2 }
>     tripMIBCompliance    OBJECT IDENTIFIER ::= { tripMIBConformance 1 }
>     tripMIBGroups        OBJECT IDENTIFIER ::= { tripMIBConformance 2 }
>
> --
> -- Supported protocols
> --
>     tripSupportedProtocols OBJECT IDENTIFIER ::= { tripMIBObjects 100 }

i think it would be cleaner to define these (and the addr family) oids
directly off tripMIB rather than picking some arbitrarily high
oid space under tripMIBObjects.

eg,
tripSupportedProtocols OBJECT IDENTIFIER ::= { tripMIB 3 }
tripAddressFamilies    OBJECT IDENTIFIER ::= { tripMIB 4 }

[DZ] I have changed tripSupportedProtocols and tripAddressFamilies to
OBJECT-IDENTITY because it is more descriptive of their function. Is
it ok to have these under one more level? For example

tripStaticConfigObjects OBJECT IDENTIFIER ::= { tripMIB 3 }
tripSupportedProtocols OBJECT-IDENTITY
       STATUS        current
       DESCRIPTION
           "Registration point for the protocols supported by TRIP."
       ::= { tripStaticConfigObjects 1 }

tripAddressFamilies OBJECT-IDENTITY
       STATUS        current
       DESCRIPTION
           "Registration point for the address families supported by
           TRIP."
       ::= { tripStaticConfigObjects 2 }


>
>     tripSupProtSIP
>         OBJECT IDENTIFIER ::= { tripSupportedProtocols 1 }
>     tripSupProtH323Q931
>         OBJECT IDENTIFIER ::= { tripSupportedProtocols 2 }
>     tripSupProtH323RAS
>         OBJECT IDENTIFIER ::= { tripSupportedProtocols 3 }
>     tripSupProtH323ANNEXG
>         OBJECT IDENTIFIER ::= { tripSupportedProtocols 4 }
>
> --
> -- Address Families
> --
>     tripAddressFamilies    OBJECT IDENTIFIER ::= { tripMIBObjects 101 }
>
>     tripAddrFamilyDecimal
>         OBJECT IDENTIFIER ::= { tripAddressFamilies 1 }
>     tripAddrFamilyPentadecimal
>         OBJECT IDENTIFIER ::= { tripAddressFamilies 2 }
>     tripAddrFamilyE164
>         OBJECT IDENTIFIER ::= { tripAddressFamilies 3 }
>
> --
> -- tripCfgTable
> --
>    tripCfgTable OBJECT-TYPE
>        SYNTAX     SEQUENCE OF TripCfgEntry
>        MAX-ACCESS not-accessible
>        STATUS     current
>        DESCRIPTION
>            "This table contains the common configuration objects
>             applicable to all TRIP entities.  Each row represents
>             those objects for a particular TRIP LS present in
>             this system. The instances of TRIP LS's are
>             uniquely identified by applIndex."

the description here indicates that the info in this table is
wrt the trip ls present on this system.  the use of the work
"peer" in later descriptions makes me think the information
might be wrt a peer trip ls elsewhere in the network.
perhaps all trip entities are referred to as Peers and
you are still actually talking about the local trip entity.
it's a bit confusing, can that be clarified?

[DZ] Yes it is a bit confusing. "All TRIP entities" refer to all the
local TRIP applications referenced by the applIndex. I will try to
make this clearer. 



>        ::= { tripMIBObjects 1 }
>
>    tripCfgEntry OBJECT-TYPE
>        SYNTAX     TripCfgEntry
>        MAX-ACCESS not-accessible
>        STATUS     current
>        DESCRIPTION
>            "A row of common configuration."
>        INDEX { applIndex }
>        ::= { tripCfgTable 1 }
>
>    TripCfgEntry ::=
>        SEQUENCE {
>            tripProtocolVersion               Integer32,
>            tripLocalItad                     TripItad,
>            tripIdentifier                    TripId,
>            tripOperStatus                    INTEGER,
>            tripAdminStatus                   INTEGER,
>            tripLocalAddrIAddrType            InetAddressType,
>            tripLocalAddr                     InetAddress,
>            tripLocalPort                     Integer32,
>            tripMinItadOriginationInterval    Integer32,
>            tripMinRouteAdvertisementInterval Integer32,
>            tripMaxPurgeTime                  Integer32,
>            tripDisableTime                   Integer32,
>            tripSendReceiveMode               INTEGER
>       }
>
>    tripProtocolVersion    OBJECT-TYPE
>        SYNTAX     Integer32 (1..255)
>        MAX-ACCESS read-only
>        STATUS     current
>        DESCRIPTION
>            "This object will reflect the version of TRIP
>            supported by this system.  It follows the same
>            format as TRIP version information contained
>            in the TRIP messages generated by this TRIP entity
>            as dictated by draft-ietf-iptel-trip-07.txt."

try to avoid referencing I-D documents.  the information will
be stale long before these mib object definitions are obsolete.
if you must for clarity, i understand, but expect to have to
remove/revise it in later revisions of the mib and put it
in a REFERENCE clause rather than the DESCRIPTION.  the
DESCRIPTION here could just say "... as dictated by the
TRIP standard."

[DZ] Done.


>        ::= { tripCfgEntry 1 }
>
>    tripLocalItad   OBJECT-TYPE
>        SYNTAX      TripItad
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>            "The Local Internet Telephony Administrative domain."
>        ::= { tripCfgEntry 2 }
>
>    tripIdentifier   OBJECT-TYPE
>        SYNTAX      TripId
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The object that identifies this TRIP Client."
>        ::= { tripCfgEntry 3 }
>
>    tripAdminStatus OBJECT-TYPE
>        SYNTAX      INTEGER {
>                        up(1),
>                        down(2)
>                    }
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>            "The desired TRIP state.
>
>             up(1)  : Set the application to normal operation.
>
>             down(2): Set the application to a state where it will not
>                      process TRIP messages."

gee, i wish we could simplify our sip mib admin status down to
this ;)

>        ::= { tripCfgEntry 4 }
>
>    tripOperStatus OBJECT-TYPE
>        SYNTAX      INTEGER {
>                        up(1),
>                        down(2)
>                    }
>        MAX-ACCESS  read-write

oper status should be read-only.


>        STATUS      current
>        DESCRIPTION
>            "The current operational state of the TRIP protocol.
>
>             up(1)  : The application is operating normally, and
>                      is processing (receiving and possibly
>                      issuing) TRIP requests and responses.
>
>             down(2): The application is currently unable to
>                      process TRIP messages due to a fault or if
>                      TRIP is in an initialization state.
>
>            If tripAdminStatus is down(2) then tripOperStatus should be
>            down(2). If tripAdminStatus is changed to up(1) then
>            tripOperStatus should change to up(1) if there is no fault
>            that prevents the TRIP protocol from moving to the up(1)
>            state."

consider adding another oper state that the appl can be in if
there is a fault of some sort.

[DZ] do we really need a new state for faulty? Faults will covered by
the notifications.


>        ::= { tripCfgEntry 5 }
>
>    tripLocalAddrIAddrType OBJECT-TYPE
>        SYNTAX      InetAddressType
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The type of Inet Address of the tripLocalAddr."
>        REFERENCE
>            "RFC 2851, section 3."
>        ::= { tripCfgEntry 6 }
>
>    tripLocalAddr OBJECT-TYPE
>        SYNTAX      InetAddress
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The IP address of this entry's TRIP peer connection."

here is one of the confusing spots...
is this an address of a peer trip entity? if so, then the use of
"Local" in the obj descriptor seems strange.

[DZ] I agree. tripAddr is better. Same for tripPort, tripItad...


>        REFERENCE
>            "RFC 2851, section 3."
>        ::= { tripCfgEntry 7 }
>
>    tripLocalPort OBJECT-TYPE
>        SYNTAX      Integer32 (1..65535)
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>            "The local port that this entry's TRIP peer is using."

again, i'm a bit confused.  the description talks about a trip peer
using this port, but the "Local" reference in the obj has me confused.

also, is this s tcp/udp port or an "interface" on the box?  port
can be an ambiguous term in the world of networking, so please
be more specific.

[DZ] agree.

>        ::= { tripCfgEntry 8 }
>
>    tripMinItadOriginationInterval OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)

any reason not to use the SNMPv2-TC
TimeInterval ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
            "A period of time, measured in units of 0.01 seconds."
    SYNTAX       INTEGER (0..2147483647)
?

is the 0 value of TimeInterval a problem?

>        UNITS       "Seconds"

if TimeInterval was used, UNITS would either come out of the mib
or need to reflect "hundreths of a second".

[DZ] Since we don't need the granularity of "hundredths of a second"
and this object starts at 1, I think that it would more descriptive
to leave the object as is.


>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>            "Amount of time that must elapse between advertisement
>            of update message that report changes within the
>            Location Server's own ITAD."
>        DEFVAL { 30 }

DEFVAL would go to 3000 if TimeInterval used.

>        ::= { tripCfgEntry 9 }
>
>    tripMinRouteAdvertisementInterval OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)

same comment wrt TimeInterval TC.

[DZ] See above.


>        UNITS       "Seconds"
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>            "Specifies minimal interval between successive
>            advertisement to a particular destination from an LS."
>        DEFVAL { 30 }
>        ::= { tripCfgEntry 10 }
>
>    tripMaxPurgeTime OBJECT-TYPE
>        SYNTAX      Integer32 (1..65535)

same comment wrt TimeInterval TC.

>        UNITS       "Seconds"
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>            "Indicate the interval that the location server must
>            maintain routes marked as withdrawn in its database."
>        DEFVAL { 10 }
>        ::= { tripCfgEntry 11 }
>
>    tripDisableTime OBJECT-TYPE
>        SYNTAX      Integer32 (1..65535)

same comment wrt TimeInterval TC.

>        UNITS       "Seconds"
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>            "Indicate the interval that the TRIP module of the
>             location server must be disabled while routes
>             originated by this location server with high
>             sequence numbers can be removed."
>        DEFVAL { 180 }
>        ::= { tripCfgEntry 12 }
>
>    tripSendReceiveMode OBJECT-TYPE
>        SYNTAX INTEGER {
>                sendReceive(1),
>                sendOnly(2),
>                receiveOnly(3)
>                }
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The operational mode of this peer."

the trip entity running on this system??

[DZ] Yes.


>        ::= { tripCfgEntry 13 }
>
> --
> -- tripSupportedCommunityTable
> --
>
>    tripSupportedCommunityTable   OBJECT-TYPE
>        SYNTAX      SEQUENCE OF TripSupportedCommunityEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The list of TRIP communities that this LS supports. A TRIP
>            community is a group of destinations that share some common
>            property.

property -> properties.

[DZ] agree.

>
>            The TRIP Communities attribute is used to group destinations
>            so that the routing decision can be based on the identity of
>            the group."
>        REFERENCE
>            "draft-ietf-iptel-trip-07.txt, J. Rosenberg et al,
>            section 5.9."

again be aware of the pitfalls of referencing drafts.  -09 is the
current
draft i think, so this info is essentially stale already.

[DZ] agree.

>        ::= { tripMIBObjects 2 }
>
>    tripSupportedCommunityEntry OBJECT-TYPE
>        SYNTAX      TripSupportedCommunityEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Entry containing information a community. A TRIP

say "... information about a community."

[DZ] Done.

>            community is a group of destinations that share some
>            common property."

typically, what's that "common property" the destination share?

[DZ] I have made the description more descriptive.

>        INDEX { applIndex, tripSupportedCommunityId }
>        ::= { tripSupportedCommunityTable 1 }
>
>    TripSupportedCommunityEntry ::= SEQUENCE {
>        tripSupportedCommunityId         TripItad,
>        tripSupportedCommunityItad       TripItad,
>        tripSupportedCommunityRowStatus  RowStatus
>    }
>
>    tripSupportedCommunityId OBJECT-TYPE
>        SYNTAX      TripItad
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The identifier of the supported Community."
>        ::= { tripSupportedCommunityEntry 1 }
>
>    tripSupportedCommunityItad OBJECT-TYPE
>        SYNTAX      TripItad
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "The Itad of the community."

i'm not clear on what the differences is between the
tripSupportedCommunityId (index object) and this
tripSupportedCommunityItad??

[DZ] please see section "5.9.1. Syntax of Communities" in the TRIP spec.

>        ::= { tripSupportedCommunityEntry 2 }
>
>    tripSupportedCommunityRowStatus OBJECT-TYPE
>        SYNTAX      RowStatus
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "The row status of the entry. This object is required to
>            create or delete rows."

what is the criteria for row creation?  is the
tripSupportedCommunityItad
a required object to create a row - seems a default Itad wouldn't be
likely.  do you createAndGo or do you need to create the row and then
transition it to active w/ an additional set operation?  things like
that help implementors out tremeduously.

[DZ] I will try to make this more descriptive.

>        ::= { tripSupportedCommunityEntry 3 }
>
> --
> -- TripPeerTable
> --
>    tripPeerTable   OBJECT-TYPE
>        SYNTAX      SEQUENCE OF TripPeerEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The TRIP peer table. This table contains one entry per
>            TRIP peer, and information about the connection with
>            the peer."

so now this table seems to be info related to trip entities no
in this system, which reinforces my issues of ambiguity in the
earlier tripCfgTable (references to local and peer).

[DZ] See above

>        ::= { tripMIBObjects 4 }
>
>    tripPeerEntry OBJECT-TYPE
>        SYNTAX      TripPeerEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Entry containing information about the connection with
>            a TRIP peer."
>        INDEX { applIndex,
>                tripPeerRemoteAddrInetType,
>                tripPeerRemoteAddr }

why use the peers address objects for indexing instead of
just tripPeerIdentifier?  isn't tripPeerIdentifier unique?

[DZ] the tripPeerIdentifier is distinct, but I believe it is
easier to identify a peer from its inet address.

>          ::= {tripPeerTable 1}
>
>    TripPeerEntry ::= SEQUENCE {
>        tripPeerRemoteAddrInetType            InetAddressType,
>        tripPeerRemoteAddr                    InetAddress,
>        tripPeerIdentifier                    TripId,
>        tripPeerState                         INTEGER,
>        tripPeerAdminStatus                   INTEGER,
>        tripPeerNegotiatedVersion             Integer32,
>        tripPeerSendReceiveMode               INTEGER,
>        tripPeerRemotePort                    Integer32,
>        tripPeerRemoteItad                    TripItad,
>        tripPeerConnectRetryInterval          Integer32,
>        tripPeerMaxRetryInterval              Integer32,
>        tripPeerHoldTime                      Integer32,
>        tripPeerKeepAlive                     Integer32,
>        tripPeerHoldTimeConfigured            Integer32,
>        tripPeerKeepAliveConfigured           Integer32,
>        tripPeerMinItadOriginationInterval    Integer32,
>        tripPeerMinRouteAdvertisementInterval Integer32,
>        tripPeerMaxPurgeTime                  Integer32,
>        tripPeerDisableTime                   Integer32,
>        tripPeerRowStatus                     RowStatus
>    }
>
>    tripPeerRemoteAddrInetType OBJECT-TYPE
>        SYNTAX      InetAddressType
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The type of Inet Address of the tripPeerRemoteAddr."
>        REFERENCE
>            "RFC 2851, section 3."
>        ::= { tripPeerEntry 1 }
>
>    tripPeerRemoteAddr OBJECT-TYPE
>        SYNTAX      InetAddress (SIZE(0..125))
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The remote IP address of this entry's TRIP peer. The
>            size value of 125 has been assigned due to the sub
>            identifier of object types length limitation as
>            defined in SMIv2."

i don't understand this last sentence.   is it something about
InetAddress??  was the same not relevant for tripLocalAddr??

[DZ] The longest possible index length for an SNMP v2 entry is 128.
The applIndex takes one, the tripPeerRemoteAddrInetType takes one,
leaving 126. 125 seems reasonable. 



>        REFERENCE
>            "RFC 2851, section 3."
>        ::= { tripPeerEntry 2 }
>
>    tripPeerIdentifier OBJECT-TYPE
>        SYNTAX      TripId
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "TRIP identifier of this entry's TRIP peer."

what does it mean to be "this entry's TRIP peer"??
the peer is not a peer of this mib table entry but
rather a peer of the local TRIP LS, right?

[DZ] agreed.

>        ::= { tripPeerEntry 3 }
>
>    tripPeerState OBJECT-TYPE
>        SYNTAX      INTEGER {
>                        idle(1),
>                        connect(2),
>                        active(3),
>                        openSent(4),
>                        openConfirm(5),
>                        established(6)
>                    }
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "TRIP Peer Finite State Machine state.
>
>            idle(1)       : The initial state. Local LS refuses all
>                            incoming connections. No resources are
>                            allocated to the peer.
>
>            connect(2)    : Local LS waiting for a transport protocol
>                            connection to be completed to the peer, and
>                            is listening for inbound transport
>                            connections from the peer.
>
>            active(3)     : LS is listening for an inbound connection
>                            from the peer, but is not in the process of
>                            initiating a connection to the peer.
>
>            openSent(4)   : LS has sent an OPEN message to its peer and
>                            is waiting for an OPEN message from its
>                            peer.
>
>            openConfirm(5): LS has sent an OPEN to its peer, received an
>                            OPEN from its peer, and sent a KEEPALIVE in
>                            response to the OPEN. The LS is now waiting
>                            for a KEEPALIVE or NOTIFICATION message in
>                            response to its OPEN.
>
>            established(6): LS can exchange UPDATE, NOTIFICATION,and
>                            KEEPALIVE messages with its peer."
>        ::= { tripPeerEntry 4 }
>
>    tripPeerAdminStatus OBJECT-TYPE
>        SYNTAX      INTEGER {
>                        up(1),
>                        down(2)
>                    }
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "The desired TRIP connection state."

how might setting this to "up" affect  tripPeerState?
would tripPeerState connect->openSent->openConfirm->established?
if there is any relationship, you may want to describe it.
i may be offbase in presuming there is some relationship.

[DZ] I will look into this further.

>        ::= { tripPeerEntry 5 }
>
>    tripPeerNegotiatedVersion OBJECT-TYPE
>        SYNTAX      Integer32 (1..255)
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The negotiated version of TRIP running between this
>            local entity and this peer."
>        ::= { tripPeerEntry 6 }

this is the second object reflecting trip protocol version.
consider creating a TC TripProtocolVersion.

[DZ] done.

>
>    tripPeerSendReceiveMode OBJECT-TYPE
>        SYNTAX      INTEGER {
>                sendReceive(1),
>                sendOnly(2),
>                receiveOnly(3)
>                }
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The operational mode of this peer."

this is the same syntax as tripSendRecieveMode.
again, a good candidate for making this syntax a TC
TripSendRecvMode.

[DZ] done.

>        ::= { tripPeerEntry 7 }
>
>    tripPeerRemotePort OBJECT-TYPE
>        SYNTAX      Integer32 (1..65535)
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The remote port for the TCP connection between the
>            TRIP peers."

here you are explicit about this being a tcp port.
does that answer my question regarding tripLocalPort?

[DZ] Yes

>        ::= { tripPeerEntry 8 }
>
>    tripPeerRemoteItad OBJECT-TYPE
>        SYNTAX      TripItad
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "The Internet Telephony Administrative domain of
>            this peer."
>        ::= { tripPeerEntry 9 }
>
>    tripPeerConnectRetryInterval OBJECT-TYPE
>        SYNTAX      Integer32 (0..2147483647)

same comment as before on possibly using SNMPv2-TC TimeInterval.

>        UNITS       "Seconds"
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "Specifies the initial amount of time that will elapse
>            between connection retry. This value should double
>            after each attempt up to the value of
>            tripPeerMaxRetryInterval."

therefore, the value of this object has a dependency on the
value of tripPeerMaxRetryInterval.  this objects value must
always be <= tripPeerMaxRetryInterval.  attempts to set it
higher than the max retry should not be allowed, right?

[DZ] I will make it clearer.


>        DEFVAL      { 120 }
>        ::= { tripPeerEntry 10 }
>
>    tripPeerMaxRetryInterval OBJECT-TYPE
>        SYNTAX      Integer32 (0..2147483647)

same comment as before on possibly using SNMPv2-TC TimeInterval

>        UNITS       "Seconds"
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "Specifies the maximum amount of time that will elapse
>            between connection retries."

somehow refer back to the relationship between this object and
tripPeerConnectRetryInterval.  what if there's an attempt to
set this object to be less than tripPeerConnectRetryInterval?
it should fail, right?

[DZ] Agreed

>        DEFVAL      { 360 }
>        ::= { tripPeerEntry 11 }
>
>    tripPeerHoldTime OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)

same comment as before on possibly using SNMPv2-TC TimeInterval

>        UNITS       "Seconds"
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The time interval in seconds for the hold timer that
>            is established with the peer. The value of this object
>            is the smaller of the values in
>            tripPeerHoldTimeConfigured and the hold time received
>            in the open message."
>        ::= { tripPeerEntry 12 }
>
>    tripPeerKeepAlive OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)

same comment as before on possibly using SNMPv2-TC TimeInterval

>        UNITS       "Seconds"
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "Specifies the amount of time that must elapse between
>            keep alive messages."
>        ::= { tripPeerEntry 13 }
>
>    tripPeerHoldTimeConfigured OBJECT-TYPE
>        SYNTAX      Integer32 (0 | 3..65535)

same comment as before on possibly using SNMPv2-TC TimeInterval

>        UNITS       "Seconds"
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "Specifies the maximum time that may elapse between the
>            receipt of successive keepalive or update message."
>        DEFVAL { 240 }
>        ::= { tripPeerEntry 14 }
>
>    tripPeerKeepAliveConfigured OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)

same comment as before on possibly using SNMPv2-TC TimeInterval

>        UNITS       "Seconds"
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "Specifies the amount of time that must elapse between
>            keep alive messages."
>        DEFVAL { 30 }
>        ::= { tripPeerEntry 15 }
>
>    tripPeerMinItadOriginationInterval OBJECT-TYPE
>        SYNTAX      Integer32 (0..2147483647)

same comment as before on possibly using SNMPv2-TC TimeInterval

>        UNITS       "Seconds"
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "Amount of time that must elapse between advertisement
>            of update message that report changes within the Location

message -> messages

[DZ] ok

>            Server's own ITAD."
>        DEFVAL { 30 }
>        ::= { tripPeerEntry 16 }
>
>    tripPeerMinRouteAdvertisementInterval OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)

same comment as before on possibly using SNMPv2-TC TimeInterval

>        UNITS       "Seconds"
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "Specifies minimal interval between successive
>            advertisement to a particular destination from an LS."
>        DEFVAL { 30 }
>        ::= { tripPeerEntry 17 }
>
>    tripPeerMaxPurgeTime OBJECT-TYPE
>        SYNTAX      Integer32 (1..65535)

same comment as before on possibly using SNMPv2-TC TimeInterval

>        UNITS       "Seconds"
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "Indicate the interval that the location server must

either say "location server" or "LS" throughout the mib, but don't
keep switching back and forth.  i've noticed this happening.

[DZ] Changed all to LS.

>            maintain routes marked as withdrawn in its database."
>        DEFVAL { 10 }
>        ::= { tripPeerEntry 18 }
>
>    tripPeerDisableTime OBJECT-TYPE
>        SYNTAX      Integer32 (1..65535)

same comment as before on possibly using SNMPv2-TC TimeInterval

>        UNITS       "Seconds"
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "Indicate the interval that the TRIP module of the

the peer LS presumably?

>            location server must be disabled while routes
>            originated by this location server with high sequence

is "this" referring to the local ls or the peer ls.

[DZ] Fixed

>            numbers can be removed."
>        DEFVAL { 180 }
>        ::= { tripPeerEntry 19 }
>
>    tripPeerRowStatus OBJECT-TYPE
>        SYNTAX      RowStatus
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "This object is used to create and delete rows in the
>            tripPeerTable."

again, row creation criteria should be added to aid implementors
and nm appl developers.

>        ::= { tripPeerEntry 20 }
>
> --
> --     tripPeerRouteTypeTable
> --
>     tripPeerRouteTypeTable OBJECT-TYPE
>       SYNTAX      SEQUENCE OF TripPeerRouteTypeEntry
>       MAX-ACCESS  not-accessible
>       STATUS      current
>       DESCRIPTION
>           "The TRIP peer Route Type table. This table contains one
>           entry per supported protocol - address family pair."
>       ::= { tripMIBObjects 5 }
>
>     tripPeerRouteTypeEntry OBJECT-TYPE
>       SYNTAX      TripPeerRouteTypeEntry
>       MAX-ACCESS  not-accessible
>       STATUS      current
>       DESCRIPTION
>           "Entry containing information about the route type that
>           the TRIP peer supports."
>       INDEX { applIndex,
>               tripPeerRemoteAddrInetType,
>               tripPeerRemoteAddr,

if tripPeerIdentifier is viable, use it instead of address objects.

>               tripPeerRtTypeProtocolId,
>               tripPeerRtTypeAddrFamilyId }

why do these need to be part of the index??
they are oids themselves.  your index into this
table, just to retrieve the value of the RowStatus
object could be very large and cumbersome.

why aren't the protoclid and addrfamily oids the
data retrieved from this table as object values
rather than index components?

[DZ] Both these fields make the entry unique, therefore, both are needed in the index.

>         ::= { tripPeerRouteTypeTable 1 }
>
>     TripPeerRouteTypeEntry ::= SEQUENCE {
>         tripPeerRtTypeProtocolId         TripAppProtocol,
>         tripPeerRtTypeAddrFamilyId       TripAddressFamily,
>         tripPeerRtTypeRowStatus          RowStatus
>     }
>
>     tripPeerRtTypeProtocolId OBJECT-TYPE
>       SYNTAX      TripAppProtocol
>       MAX-ACCESS  not-accessible
>       STATUS      current
>       DESCRIPTION
>           "The object identifier of a protocol that this peer is
>           using."
>       ::= { tripPeerRouteTypeEntry 1 }
>
>     tripPeerRtTypeAddrFamilyId OBJECT-TYPE
>       SYNTAX      TripAddressFamily
>       MAX-ACCESS  not-accessible
>       STATUS      current
>       DESCRIPTION
>           "The object identifier of an address family that this peer
>           belongs to."
>       ::= { tripPeerRouteTypeEntry 2 }
>
>    tripPeerRtTypeRowStatus OBJECT-TYPE
>        SYNTAX      RowStatus
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object is used to instantiate a row in this table.
>            The normal row status values of createAndGo(4),
>            createAndWait(5) and delete(6) have no application in this
>            table."

good, some beginnings of the row creation criteria that i have been
mentioning.  now why not applicable here?   if i can't
do createAndGo or createAndWait then how do i create a row in this
table?  are these rows instantiated via trip and not by a nms??
i'm confused.

[DZ] The row status object is used only to instantiate the row in the table. If the two index objects could be made read-only instead of not accessible, then the row status would not be needed.

>        ::= { tripPeerRouteTypeEntry 3 }
>
> --
> -- TripPeerStatsTable
> --
>    tripPeerStatsTable   OBJECT-TYPE
>        SYNTAX      SEQUENCE OF TripPeerStatsEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The TRIP peer stats table. This table contains one entry
>            per TRIP peer, and statistics related to the connection
>            with the peer."
>        ::= { tripMIBObjects 6 }
>
>    tripPeerStatsEntry OBJECT-TYPE
>        SYNTAX      TripPeerStatsEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Entry containing information about the connection with
>            a TRIP peer."
>        AUGMENTS { tripPeerEntry }
>          ::= { tripPeerStatsTable 1 }
>
>    TripPeerStatsEntry ::= SEQUENCE {
>        tripPeerInUpdates                   Counter32,
>        tripPeerOutUpdates                  Counter32,
>        tripPeerInTotalMessages             Counter32,
>        tripPeerOutTotalMessages            Counter32,
>        tripPeerFsmEstablishedTransitions   Counter32,
>        tripPeerFsmEstablishedTime          DateAndTime,
>        tripPeerInUpdateElapsedTime         Gauge32
>    }
>
>     tripPeerInUpdates OBJECT-TYPE
>        SYNTAX      Counter32
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The number of TRIP update messages received from this
>            peer since the last restart of this location server."
>        ::= { tripPeerStatsEntry 1 }
>
>    tripPeerOutUpdates OBJECT-TYPE
>        SYNTAX      Counter32
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The number of TRIP update messages transmitted to

transmitted -> sent.... consistent w/ other parts of the mib
using send/receive terminology.  i know.... a real nit! ;)

[DZ] ok.

>            this peer since the last restart of this location
>            server."
>        ::= { tripPeerStatsEntry 2 }
>
>    tripPeerInTotalMessages OBJECT-TYPE
>        SYNTAX      Counter32
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The total number of TRIP messages received to the

to -> from

[DZ] ok.

>            remote peer on this connection since the last restart
>            of this location server."
>        ::= { tripPeerStatsEntry 3 }
>
>    tripPeerOutTotalMessages OBJECT-TYPE
>        SYNTAX      Counter32
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The total number of outgoing TRIP messages sent since

for consistency sake... say "...sent to the remote peer since...."

[DZ] ok.

>            the last restart of this location server."
>        ::= { tripPeerStatsEntry 4 }
>
>    tripPeerFsmEstablishedTransitions OBJECT-TYPE
>        SYNTAX      Counter32
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The number of times the TRIP peer has transitioned into
>            the established state since the last restart of this
>            location server."
>        ::= { tripPeerStatsEntry 5 }
>
>    tripPeerFsmEstablishedTime OBJECT-TYPE
>        SYNTAX      DateAndTime
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "Indicates how long in seconds this peer has been in the
>            established state."

description doesn't match up w/ the syntax.  DateAndTime is more
than just seconds.

[DZ] agreed.

>        ::= { tripPeerStatsEntry 6 }
>
>    tripPeerInUpdateElapsedTime OBJECT-TYPE
>        SYNTAX      Gauge32
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "Elapsed time in seconds since the last TRIP update
>            message was received from the peer."

not sure why Gauge32 is used here.  again, why not TimeInterval.
description would have to not refer to seconds.

[DZ] I agree that a gauge might not be the best thing to use here. I think this is an appropriate place to use TimeInterval.

i have to stop here.  i will send more comments on the remainder
of the mib early next week.

kevin
>        ::= { tripPeerStatsEntry 7 }
>
> -- TRIP Received Route Table.  This table contains
> -- all routes from all sources. Each entry consists
> -- of a route and its associated path attributes.
>
>    tripRouteTable OBJECT-TYPE
>        SYNTAX      SEQUENCE OF TripRouteEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The TRIP route table containing information about
>            reachable routes that are to be added to service by the
>            receiving LS."
>        ::= { tripMIBObjects 7 }
>
>    tripRouteEntry OBJECT-TYPE
>        SYNTAX      TripRouteEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Information about a route to a called destination."
>        INDEX { applIndex,
>                tripRouteAppProtocol,
>                tripRouteAddressFamily,
>                tripRouteAddress,
>                tripRoutePeer
>                }
>        ::= { tripRouteTable 1 }
>
>    TripRouteEntry ::= SEQUENCE {
>                tripRouteAppProtocol                 TripAppProtocol,
>                tripRouteAddressFamily               TripAddressFamily,
>                tripRouteAddress                     OCTET STRING,
>                tripRoutePeer                        TripId,
>                tripRouteAddressSequenceNumber       Integer32,
>                tripRouteAddressOriginatorId         TripItad,
>                tripRouteNextHopServerIAddrType      InetAddressType,
>                tripRouteNextHopServer               InetAddress,
>                tripRouteNextHopServerPort           Integer32,
>                tripRouteNextHopServerItad           TripItad,
>                tripRouteMultiExitDisc               Unsigned32,
>                tripRouteLocalPref                   Unsigned32,
>                tripRouteAdvertisementPath           OCTET STRING,
>                tripRouteRoutedPath                  OCTET STRING,
>                tripRouteAtomicAggregate             TruthValue,
>                tripRouteBest                        TruthValue,
>                tripRouteUnknown                     OCTET STRING,
>                tripRouteWithdrawn                   TruthValue,
>                tripRouteConverted                   TruthValue
>            }
>
>    tripRouteAppProtocol OBJECT-TYPE
>        SYNTAX      TripAppProtocol
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The protocol for which this routing table is
>            maintained."
>        ::= { tripRouteEntry 1 }
>
>    tripRouteAddressFamily OBJECT-TYPE
>        SYNTAX      TripAddressFamily
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Specifies the type of address for the destination
>            route."
>        ::= { tripRouteEntry 2 }
>
>    tripRouteAddress OBJECT-TYPE
>        SYNTAX      OCTET STRING (SIZE(1..32))
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "This is an address (prefix) of the family type given by
>            Address Family of the destination."
>        ::= { tripRouteEntry 3 }
>
>    tripRoutePeer OBJECT-TYPE
>        SYNTAX      TripId
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The identifier of the peer where the route information
>            was learned."
>        ::= { tripRouteEntry 4 }
>
>    tripRouteAddressSequenceNumber OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "Indicates the version of the destination route
>            originated by the location server identified by
>            tripRouteAddressOriginatorId intra-domain
>            attribute."
>        ::= { tripRouteEntry 5 }
>
>    tripRouteAddressOriginatorId OBJECT-TYPE
>        SYNTAX      TripItad
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This is an intra-domain attribute indicating the
>            internal location server that originated the route
>            into the ITAD."
>        ::= { tripRouteEntry 6 }
>
>    tripRouteNextHopServerIAddrType OBJECT-TYPE
>        SYNTAX      InetAddressType
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The type of Inet Address of the tripRouteNextHopServer."
>        REFERENCE
>            "RFC 2851, section 3."
>        ::= { tripRouteEntry 7 }
>
>    tripRouteNextHopServer OBJECT-TYPE
>        SYNTAX      InetAddress
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "Indicates the next hop that messages of a given
>            protocol destined for tripRouteAddress should
>            be sent to."
>        ::= { tripRouteEntry 8 }
>
>    tripRouteNextHopServerPort OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The port of the next hop server that this route
>            will use."
>        ::= { tripRouteEntry 9 }
>
>    tripRouteNextHopServerItad OBJECT-TYPE
>        SYNTAX      TripItad
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "Indicates the domain of the next hop."
>        ::= { tripRouteEntry 10 }
>
>    tripRouteMultiExitDisc OBJECT-TYPE
>        SYNTAX      Unsigned32 (0..4294967295)
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "When two ITADs are connected by more than one set of peers,
>            it is used to descriminate between multiple exit points to
>            an adjacent ITAD."
>        ::= { tripRouteEntry 11 }
>
>    tripRouteLocalPref OBJECT-TYPE
>        SYNTAX      Unsigned32 (0..4294967295)
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "Indicated the local LS's degree of preference for an
>            advertised route destination."
>        ::= { tripRouteEntry 12 }
>
>    tripRouteAdvertisementPath OBJECT-TYPE
>        SYNTAX      OCTET STRING (SIZE(4..252))
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "Identifies the ITADs through wich routing information
>            carried in an advertisement has passed.
>
>            This object is probably best represented as sequence of
>            integer. For SMI compatibility, though, it is represented
>            as OCTET STRING. This object is a sequence of ITADs in
>            network byte order."
>        ::= { tripRouteEntry 13 }
>
>    tripRouteRoutedPath OBJECT-TYPE
>        SYNTAX      OCTET STRING (SIZE(4..252))
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "Identifies the ITADs through which messages sent using
>            this route would pass. These are as subset of
>            tripRouteAdvertisementPath.
>
>            This object is probably best represented as sequence of
>            integer. For SMI compatibility, though, it is represented
>            as OCTET STRING.  This object is a sequence of ITADs in
>            network byte order."
>        ::= { tripRouteEntry 14 }
>
>    tripRouteAtomicAggregate OBJECT-TYPE
>        SYNTAX      TruthValue
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "Indicates that a route may traverse domains not listed in
>            tripRouteRoutedPath. If an LS selects the less specific
>            route from a set of overlapping routes, then this value
>            returns TRUE."
>        ::= { tripRouteEntry 15 }
>
>    tripRouteBest OBJECT-TYPE
>        SYNTAX      TruthValue
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "An indication of whether this route was chosen as the
>            best TRIP route."
>        ::= { tripRouteEntry 16 }
>
>    tripRouteUnknown OBJECT-TYPE
>        SYNTAX      OCTET STRING (SIZE(0..255))
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "One or more attributes not understood by this location
>            server."
>        ::= { tripRouteEntry 17 }
>
>    tripRouteWithdrawn OBJECT-TYPE
>        SYNTAX      TruthValue
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "Indicates if this route is to be removed from service by
>            the receiving LS."
>        ::= { tripRouteEntry 18 }
>
>    tripRouteConverted OBJECT-TYPE
>        SYNTAX TruthValue
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "Indicates if this route has been converted to a
>            different application protocol than it had originally."
>        ::= { tripRouteEntry 19 }
>
> --
> -- TRIP Received Route CommunityTable.
> --
>
>    tripRouteCommunityTable OBJECT-TYPE
>        SYNTAX      SEQUENCE OF TripRouteCommunityEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "A table containing a list of TRIP communities associated
>            with a route."
>        REFERENCE
>            "draft-ietf-iptel-trip-07.txt, J. Rosenberg et al,
>            section 5.9."
>        ::= { tripMIBObjects 8 }
>
>    tripRouteCommunityEntry OBJECT-TYPE
>        SYNTAX      TripRouteCommunityEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Information about communities associated with a route. An
>            entry with a tripRouteAddress of 00 and a tripRoutePeer of
>            0 refers to the local LS."
>        INDEX { applIndex,
>                tripRouteAppProtocol,
>                tripRouteAddressFamily,
>                tripRouteAddress,
>                tripRoutePeer,
>                tripRouteCommunityId
>              }
>        ::= { tripRouteCommunityTable 1 }
>
>    TripRouteCommunityEntry ::= SEQUENCE {
>         tripRouteCommunityId    TripItad,
>         tripRouteCommunityItad  TripItad
>         }
>
>    tripRouteCommunityId OBJECT-TYPE
>        SYNTAX      TripItad
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The community identifier."
>        ::= { tripRouteCommunityEntry 1 }
>
>    tripRouteCommunityItad OBJECT-TYPE
>        SYNTAX      TripItad
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The ITAD associated with this community."
>        ::= { tripRouteCommunityEntry 2 }
>
> --
> -- tripItadTopologyTable
> --
>
>    tripItadTopologyTable OBJECT-TYPE
>        SYNTAX      SEQUENCE OF TripItadTopologyEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The sequence of link connections between peers within
>            an ITAD."
>        ::= { tripMIBObjects 9 }
>
>    tripItadTopologyEntry OBJECT-TYPE
>        SYNTAX      TripItadTopologyEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Information about a peer of the location server identified
>            by tripOriginatorIdentifier."
>        INDEX { applIndex, tripItadTopologyOrigId }
>        ::= { tripItadTopologyTable 1 }
>
>    TripItadTopologyEntry ::= SEQUENCE {
>                tripItadTopologyOrigId    TripItad,
>                tripItadTopologySeqNum    Integer32
>            }
>
>    tripItadTopologyOrigId OBJECT-TYPE
>        SYNTAX      TripItad
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Indicates the internal location server that originated
>            the ITAD topology information into the ITAD."
>        ::= { tripItadTopologyEntry 1 }
>
>    tripItadTopologySeqNum OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "Indicates the version of the ITAD topology
>            originated by the location server identified by
>            tripOriginatorIdentifier."
>        ::= { tripItadTopologyEntry 2 }
>
> --
> -- tripItadTopologyIdTable
> --
>
>    tripItadTopologyIdTable OBJECT-TYPE
>        SYNTAX      SEQUENCE OF TripItadTopologyIdEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The list of other location servers within the ITAD
>            domain that the location server identified by
>            tripOriginatorIdentifier is currently peering."
>        ::= { tripMIBObjects 10 }
>
>    tripItadTopologyIdEntry OBJECT-TYPE
>        SYNTAX      TripItadTopologyIdEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Information about a peer to the location server
>            identified by tripOriginatorIdentifier."
>        INDEX { applIndex,
>                tripItadTopologyOrigId,
>                tripItadTopologyId }
>        ::= { tripItadTopologyIdTable 1 }
>
>    TripItadTopologyIdEntry ::= SEQUENCE {
>                tripItadTopologyId            TripId,
>                tripItadTopologyIdRowStatus   RowStatus
>            }
>
>    tripItadTopologyId OBJECT-TYPE
>        SYNTAX      TripId
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The index into this entry. Indicates the other location
>            servers within the ITAD domain that this location server
>            identified by tripOriginatorIdentifier is currently
>            peering."
>        ::= { tripItadTopologyIdEntry 1 }
>
>    tripItadTopologyIdRowStatus OBJECT-TYPE
>        SYNTAX      RowStatus
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object is used to instantiate a row in this table.
>            The normal row status values of createAndGo(4),
>            createAndWait(5) and delete(6) have no application in this
>            table."
>        ::= { tripItadTopologyIdEntry 2 }
>
> --
> -- Notification objects
> --
>
>    tripNotifApplIndex    OBJECT-TYPE
>        SYNTAX     INTEGER (1..2147483647)
>        MAX-ACCESS accessible-for-notify
>        STATUS     current
>        DESCRIPTION
>             "This object contains the applIndex as described
>             in RFC 2788. It is used to bind this notification
>             with a specific instance of TRIP entity."
>        ::= { tripMIBNotifications 1 }
>
>    tripNotifPeerAddrInetType OBJECT-TYPE
>        SYNTAX      InetAddressType
>        MAX-ACCESS  accessible-for-notify
>        STATUS      current
>        DESCRIPTION
>            "The type of Inet Address of the tripNotifPeerAddr."
>        REFERENCE
>            "RFC 2851, section 3."
>        ::= { tripMIBNotifications 2 }
>
>    tripNotifPeerAddr OBJECT-TYPE
>        SYNTAX      InetAddress (SIZE(0..125))
>        MAX-ACCESS  accessible-for-notify
>        STATUS      current
>        DESCRIPTION
>            "The remote IP address of this entry's TRIP peer. The
>            size value of 125 has been assigned due to the sub
>            identifier of object types length limitation as
>            defined in SMIv2."
>        REFERENCE
>            "RFC 2851, section 3."
>        ::= { tripMIBNotifications 3 }
>
>    tripNotifPeerErrCode OBJECT-TYPE
>        SYNTAX      INTEGER {
>                        messageHeader(1),
>                        openMessage(2),
>                        updateMessage(3),
>                        holdTimerExpired(4),
>                        finiteStateMachine(5),
>                        cease(6),
>                        tripNotification(7)
>                    }
>        MAX-ACCESS  accessible-for-notify
>        STATUS      current
>        DESCRIPTION
>            "Notification message of TRIP error. The meaning of this
>            value is applicable to the following functions:
>
>            1 - message header.
>                All errors detected while processing the TRIP message
>                header.
>            2 - open message.
>                All errors detected while processing the OPEN message.
>            3 - update message.
>                All errors detected while processing the UPDATE message.
>            4 - hold timer expired.
>                A notification generated when the hold timer expires.
>            5 - finite state machine.
>                All errors detected by the TRIP Finite State Machine.
>            6 - cease.
>                Any fatal error condition that the rest of the values
>                do not cover.
>            7 - trip notification message.
>                Any error encountered while sending a notification
>                message."
>       ::= { tripMIBNotifications 4 }
>
>    tripNotifPeerErrSubcode OBJECT-TYPE
>        SYNTAX      Integer32 (1..7)
>        MAX-ACCESS  accessible-for-notify
>        STATUS      current
>        DESCRIPTION
>            "The sub error code associated with error code. The meaning
>            of this value is dependent on the value of
>            tripNotifPeerErrCode.
>
>            Message Header (1) Error Subcodes:
>            1 - Bad Message Length.
>            2 - Bad Message Type.
>
>            OPEN Message (2) Error Subcodes:
>            1 - Unsupported Version Number.
>            2 - Bad Peer ITAD.
>            3 - Bad TRIP Identifier.
>            4 - Unsupported Optional Parameter.
>            5 - Unacceptable Hold Time.
>            6 - Unsupported Capability.
>            7 - Capability Mismatch.
>
>            UPDATE Message (3) Error Subcodes:
>            1 - Malformed Attribute List.
>            2 - Unrecognized Well-known Attribute.
>            3 - Missing Well-known Mandatory Attribute.
>            4 - Attribute Flags Error.
>            5 - Attribute Length Error.
>            6 - Invalid Attribute."
>       ::= { tripMIBNotifications 5 }
>
> --
> -- Notifications
> --
>    tripEstablished NOTIFICATION-TYPE
>        STATUS  current
>        DESCRIPTION
>            "The TRIP Established event is generated when the TRIP
>            FSM enters the ESTABLISHED state."
>        ::= { tripMIBNotifications 6 }
>
>    tripFSM NOTIFICATION-TYPE
>        OBJECTS { tripNotifApplIndex,
>                  tripNotifPeerAddrInetType,
>                  tripNotifPeerAddr,
>                  tripNotifPeerErrCode,
>                  tripNotifPeerErrSubcode,
>                  tripPeerState
>                }
>        STATUS  current
>        DESCRIPTION
>            "The trip FSM Event is generated when any error is detected
>            by the TRIP Finite State Machine."
>        ::= { tripMIBNotifications 7 }
>
>    tripOpenMessageError NOTIFICATION-TYPE
>        OBJECTS { tripNotifApplIndex,
>                  tripNotifPeerAddrInetType,
>                  tripNotifPeerAddr,
>                  tripNotifPeerErrCode,
>                  tripNotifPeerErrSubcode,
>                  tripPeerState
>                }
>        STATUS  current
>        DESCRIPTION
>            "Errors detected while processing the OPEN message."
>        ::= { tripMIBNotifications 8 }
>
>    tripUpdateMessageError NOTIFICATION-TYPE
>        OBJECTS { tripNotifApplIndex,
>                  tripNotifPeerAddrInetType,
>                  tripNotifPeerAddr,
>                  tripNotifPeerErrCode,
>                  tripNotifPeerErrSubcode,
>                  tripPeerState
>                }
>        STATUS  current
>        DESCRIPTION
>            "Errors detected while processing the UPDATE message."
>        ::= { tripMIBNotifications 9 }
>
>    tripHoldTimerExpired NOTIFICATION-TYPE
>        OBJECTS { tripNotifApplIndex,
>                  tripNotifPeerAddrInetType,
>                  tripNotifPeerAddr,
>                  tripNotifPeerErrCode,
>                  tripNotifPeerErrSubcode,
>                  tripPeerState
>                }
>        STATUS  current
>        DESCRIPTION
>            "The system does not receive successive messages within the
>            period specified by the negotiated Hold Time."
>        ::= { tripMIBNotifications 10 }
>
>    tripConnectionCollision NOTIFICATION-TYPE
>        OBJECTS { tripNotifApplIndex }
>        STATUS  current
>        DESCRIPTION
>            "A pair of LSs tried to simultaneously to establish a
>            transport connection to each other."
>        ::= { tripMIBNotifications 11 }
>
>    tripNotificationErr NOTIFICATION-TYPE
>        OBJECTS { tripNotifApplIndex }
>        STATUS  current
>        DESCRIPTION
>            "Generated if there is an error detected in a TRIP
>            notification message sent with another cause. Note that
>            the TRIP notification refered to in this object is not
>            an SNMP notification, it is a specific message described
>            in the TRIP specification."
>        REFERENCE
>            "draft-ietf-iptel-trip-07.txt, J. Rosenberg et al,
>            section 6.4."
>        ::= { tripMIBNotifications 12 }
>
>    --
>    -- Compliance Statements
>    --
>    tripCompliance MODULE-COMPLIANCE
>        STATUS     current
>        DESCRIPTION
>             "The compliance statement for TRIP entities."
>
>        MODULE -- this module
>             MANDATORY-GROUPS { tripConfigGroup,
>                                tripPeerTableConfigGroup,
>                                tripRouteGroup,
>                                tripItadTopologyGroup,
>                                tripPeerTableStatsGroup }
>
>        GROUP tripNotificationGroup
>        DESCRIPTION
>            "This group is optional. A TRIP entity can choose not to
>            send any notifications. If this group is implemented, the
>            tripNotifObjectGroup must also be implemented."
>
>        GROUP tripNotifObjectGroup
>        DESCRIPTION
>            "This group is optional. A TRIP entity can choose not to
>            send any notifications. If this group is implemented, the
>            tripNotificationGroup must also be implemented."
>
>        MODULE NETWORK-SERVICES-MIB
>             MANDATORY-GROUPS { applRFC1565Group }
>
>        ::= { tripMIBCompliance 1 }
>
> --
> -- Object and event conformance groups
> --
>
>    tripConfigGroup OBJECT-GROUP
>        OBJECTS {
>            tripProtocolVersion,
>            tripLocalItad,
>            tripIdentifier,
>            tripOperStatus,
>            tripAdminStatus,
>            tripLocalAddrIAddrType,
>            tripLocalAddr,
>            tripLocalPort,
>            tripMinItadOriginationInterval,
>            tripMinRouteAdvertisementInterval,
>            tripMaxPurgeTime,
>            tripDisableTime,
>            tripSendReceiveMode,
>            tripSupportedCommunityItad,
>            tripSupportedCommunityRowStatus
>        }
>        STATUS current
>        DESCRIPTION
>            "The global objects for configuring trip."
>        ::= { tripMIBGroups 1 }
>
>    tripPeerTableConfigGroup OBJECT-GROUP
>        OBJECTS {
>            tripPeerIdentifier,
>            tripPeerState,
>            tripPeerAdminStatus,
>            tripPeerNegotiatedVersion,
>            tripPeerSendReceiveMode,
>            tripPeerRemotePort,
>            tripPeerRemoteItad,
>            tripPeerConnectRetryInterval,
>            tripPeerMaxRetryInterval,
>            tripPeerHoldTime,
>            tripPeerKeepAlive,
>            tripPeerHoldTimeConfigured,
>            tripPeerKeepAliveConfigured,
>            tripPeerMinItadOriginationInterval,
>            tripPeerMinRouteAdvertisementInterval,
>            tripPeerMaxPurgeTime,
>            tripPeerDisableTime,
>            tripPeerRowStatus
>            }
>
>        STATUS current
>        DESCRIPTION
>            "The global objects for configuring the TRIP peer table."
>        ::= { tripMIBGroups 2 }
>
>    tripPeerTableStatsGroup OBJECT-GROUP
>        OBJECTS {
>            tripPeerInUpdates,
>            tripPeerOutUpdates,
>            tripPeerInTotalMessages,
>            tripPeerOutTotalMessages,
>            tripPeerFsmEstablishedTransitions,
>            tripPeerFsmEstablishedTime,
>            tripPeerInUpdateElapsedTime
>            }
>
>        STATUS current
>        DESCRIPTION
>            "The global statistics the TRIP peer table."
>        ::= { tripMIBGroups 3 }
>
>    tripRouteGroup OBJECT-GROUP
>        OBJECTS {
>            tripRouteAddressSequenceNumber,
>            tripRouteAddressOriginatorId,
>            tripRouteNextHopServerIAddrType,
>            tripRouteNextHopServer,
>            tripRouteNextHopServerPort,
>            tripRouteNextHopServerItad,
>            tripRouteMultiExitDisc,
>            tripRouteLocalPref,
>            tripRouteAdvertisementPath,
>            tripRouteRoutedPath,
>            tripRouteAtomicAggregate,
>            tripRouteBest,
>            tripRouteUnknown,
>            tripRouteWithdrawn,
>            tripRouteConverted,
>            tripRouteCommunityItad,
>            tripPeerRtTypeRowStatus
>            }
>
>        STATUS current
>        DESCRIPTION
>            "The global objects for configuring route attribute."
>        ::= { tripMIBGroups 4 }
>
>    tripItadTopologyGroup OBJECT-GROUP
>        OBJECTS {
>            tripItadTopologySeqNum,
>            tripItadTopologyIdRowStatus
>            }
>        STATUS current
>        DESCRIPTION
>            "The objects that define the TRIP ITAD topology."
>        ::= { tripMIBGroups 5 }
>
>    tripNotificationGroup NOTIFICATION-GROUP
>        NOTIFICATIONS {
>            tripEstablished,
>            tripFSM,
>            tripOpenMessageError,
>            tripUpdateMessageError,
>            tripHoldTimerExpired,
>            tripConnectionCollision,
>            tripNotificationErr
>        }
>        STATUS  current
>        DESCRIPTION
>             "A collection of notifications defined for TRIP."
>        ::= { tripMIBGroups 6 }
>
>    tripNotifObjectGroup OBJECT-GROUP
>        OBJECTS {
>            tripNotifApplIndex,
>            tripNotifPeerAddrInetType,
>            tripNotifPeerAddr,
>            tripNotifPeerErrCode,
>            tripNotifPeerErrSubcode
>            }
>        STATUS current
>        DESCRIPTION
>            "The collection of objects that specify information for
>            TRIP notifications."
>        ::= { tripMIBGroups 7 }
>
> END

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Kevin R. Lingle       919.392.2029
 checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police/
 Sometimes I think I understand everything, then I regain consciousness.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

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

 ------_=_NextPart_001_01C14DC9.7240253A-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From consulem2000@yahoo.com.mx Sun Oct 7 20:38:34 2001 Received: from smtp.prodigy.net.mx (dfproxy00.prodigy.net.mx [148.235.168.49] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26425 for ; Sun, 7 Oct 2001 20:38:34 -0400 (EDT) Received: from dismamex (du-148-233-91-102.prodigy.net.mx [148.233.91.102]) by SMTP.Prodigy.Net.mx (Sun Internet Mail Server sims.4.0.2001.07.26.11.50.p9) with SMTP id <0GKV0013924EYY@SMTP.Prodigy.Net.mx>; Sun, 7 Oct 2001 18:41:37 -0600 (CST) Date: Sun, 07 Oct 2001 18:35:54 -0600 From: Mercedes Flores Castaneda Subject: 20 DE OCTUBRE, SEMINARIO SERVICIO AL CLIENTE, CUPO LIMITADO To: iptel-archive@ietf.org Reply-to: consulem2000@yahoo.com.mx Message-id: <0GKV001XY39BYY@SMTP.Prodigy.Net.mx> MIME-version: 1.0 X-Mailer: Mailer Signature Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 8BIT Content-Transfer-Encoding: 8BIT SEMINARIO COMO INCREMENTAR LAS VENTAS A TRAVES DEL SERVICIO TEMARIO: 1. Qué es realmente el servicio al cliente? 2. Errores que se deben evitar al dar atencion y servicio al cliente. 3. Cómo afecta a la empresa un cliente descontento? 4. Como manejar a un cliente inconforme. 5. Como establecer una excelente relacion con el cliente. 6. Eficiencia en la entrega del servicio. 7. Velocidad de servicio. 8. Como incrementar los ingresos de la empresa mediante un excelente servicio. 9. Profesionalismo en la atencion y servicio al cliente. 10. Ejercicios practicos dirigidos a la aplicación de las tecnicas y conocimientos aprendidos. Fecha: 20 de Octubre Lugar: Hotel Bristol, Salon Bristol, Plaza Necaxa No. 17 Rio Panuco esq. Rio Sena, Col. Cuauhtemoc, D.F. Duracion: 8 horas, 50% del tiempo se dedica a la realizacion de ejercicios practicos. Horario: Registro 8:30 a.m. Seminario de las 9:00 a.m. a las 6:30 p.m. Dirigido a: Ejecutivos de ventas, vendedores y propietarios de negocios. Inversion: $1,900.00 por participante (más I.V.A.) Incluye: Material de apoyo, coffee breaks y comida. Conferencista Internacional: Lic. Ricardo Colin Morales Con más de 20 años de experiencia capacitando a miles de vendedores para la industria. RESERVE SUS LUGARES HOY MISMO TELS. 55 43 59 61 Y 55 43 57 81 CON LA LIC. MERCEDES FLORES CASTAÑEDA DIRECTORA DE RELACIONES PUBLICAS CONSULTORIA EMPRESARIAL P.D. Conforme a las leyes nacionales como internacionales este e-mail no puede ser considerado como SPAM, incluye un procedimiento para ser removido de la lista. Si desea ser removido envienos un e-mail a ricolin2002@yahoo.com.mx, indicandonos a que correo le hemos contactado y en el asunto indique "REMOVER DE LA LISTA" From iptel-admin@lists.bell-labs.com Mon Oct 8 14:07:18 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27893 for ; Mon, 8 Oct 2001 14:07:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DB5CD44338; Mon, 8 Oct 2001 13:03:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ss8mail1.ss8ott (mail.ss8.ca [209.87.228.147]) by lists.bell-labs.com (Postfix) with ESMTP id 9C7144436E for ; Fri, 5 Oct 2001 15:02:15 -0400 (EDT) Received: by mail.ss8.ca with Internet Mail Service (5.5.2650.21) id ; Fri, 5 Oct 2001 16:06:33 -0400 Message-ID: <8BAF8B40C4D2D411ADC300508BD63D69AC19F2@mail.ss8.ca> From: Jianli Wang To: "'iptel@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14DD9.3AD24DAC" Subject: [IPTEL] A question about AtomicAggregate 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 5 Oct 2001 16:06:33 -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_01C14DD9.3AD24DAC Content-Type: text/plain; charset="iso-8859-1" In TRIP version 9, there is a statement as follows (Section 5.6): "The AtomicAggregate attribute indicates that a route may traverse domains not listed in the routePath." Could anybody give me an example that this (a route traverse domains not listed in the routePath) could happen? Thanks. Jianli ------_=_NextPart_001_01C14DD9.3AD24DAC Content-Type: text/html; charset="iso-8859-1" A question about AtomicAggregate

In TRIP version 9, there is a statement as follows (Section 5.6):
"The AtomicAggregate attribute indicates that a route may traverse
domains not listed in the routePath." Could anybody give me an
example that this (a route traverse domains not listed in the routePath)
could happen? Thanks.

Jianli

------_=_NextPart_001_01C14DD9.3AD24DAC-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Oct 9 11:06:22 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05645 for ; Tue, 9 Oct 2001 11:06:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C964044337; Tue, 9 Oct 2001 10:02:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ss8mail1.ss8ott (mail.ss8.ca [209.87.228.147]) by lists.bell-labs.com (Postfix) with ESMTP id 173F244336 for ; Tue, 9 Oct 2001 09:49:56 -0400 (EDT) Received: by mail.ss8.ca with Internet Mail Service (5.5.2650.21) id <4SJQAK9C>; Tue, 9 Oct 2001 10:54:47 -0400 Message-ID: <8BAF8B40C4D2D411ADC300508BD63D69ABA3E2@mail.ss8.ca> From: David Zinman To: "'Bob Penfield'" , IPTEL List Cc: Ping Zhou , Ephraim Dobbins , Peter Commerford , "'Jonathan Rosenberg'" Subject: RE: [IPTEL] Review of draft-ietf-iptel-trip-mib-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C150D2.56736C66" 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 9 Oct 2001 10:54:46 -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_01C150D2.56736C66 Content-Type: text/plain; charset="iso-8859-1" Comments inline. > -----Original Message----- > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > Sent: Friday, September 07, 2001 2:44 PM > To: IPTEL List > Cc: Ping Zhou; Ephraim Dobbins; Peter Commerford > Subject: [IPTEL] Review of draft-ietf-iptel-trip-mib-00.txt > > > We have completed our review of the TRIP MIB and have a > number of comments > enumerated below. Special thanks to Ping Zhou, Ephraim > Dobbins, and Peter > Commerford for their assistance in this review. > > The most significant issue is that of the tripRouteTable. It > is not clear > which specific TRIBs it represents. Also, based on some of > the information > in the table, it seems to combine data from received and > derived routes > (e.g. tripRouteBest) which may prove problematic for implementers. If > implementers follow the TRIB structure defined in the base > spec, they may > need to instantiate another derived/combined TRIB for SNMP reporting. > Otherwise significant processing/combing of the TRIBs might > be required to > respond to a GET. I don't know whether the right thing to do is have a > separate table for each TRIB or to only report specific sets > of TRIBs. The > closest thing to what the table defined represents is the > Adj-TRIB-Ins of > internal peers plus the Ext-TRIB derived from local routes > and Adj-TRIB-Ins > of external peers. Or am I missing something? > [DZ] The TripRouteTable contains information about ALL TRIBS. However, to get a specific TRIB type, the information must be extrapolated from the objects within the entry. Three solutions to this issue: first, use different tables to represent different TRIBS. For example, we would have a TripAdjTRIBsInRouteTable, a tripExtTRIBRouteTable, a tripLocTRIBRouteTable, and a tripAdjTRIBsOutRouteTable. This is clumsy in my opinion and would have duplicate entries. Second, we could use an octet as a mask to signify which TRIB(s) the entry belongs to. For example tripRouteTRIBMask OBJECT-TYPE SYNTAX OCTET STRING(SIZE(1..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates which TRIB(s) this entry belongs to. If the least significant bit is set it would indicate that this entry is of type adj-TRIBs-ins. The second bit set would indicate ext-TRIB, the third loc-TRIB and the fourth adj-TRIB-out. 0000 0011 would indicate that the entry belongs to adj-TRIB-ins and ext-TRIB." ::= { tripRouteEntry xx } Third, we can leave the table as-is and explain better in the table description what the table represents and how to determine what TRIB the route is. > > 1) Section 4. change "with other TRIP gateways" to "between > TRIP Location > Servers". [DZ] Done. > 2) Section 4. change "" to "[2]". [DZ] Done. > 3) Section 5 & 5.1. suggest "TRIP LS" instead of "TRIP entity", or add > "(a.k.a. TRIP LS)". [DZ] Done. > 4) Several places use TripItad for community-id. Community ID > is not an ITAD > ID and should be its own type. Suggest adding CommunityId to Textual > Conventions on page 6. [DZ] Done. > 5) TripCfgEntry: Hussein said that the other timers > (ConnectRetry, HoldTime, > KeepAlive) belong here. The spec does not explicitly say > whether these are > configured for the LS (like SendReceiveMode) or on a per-peer > basis. The MIB > defines them as per-peer parameters (in TripPeerEntry). > However, a given > implementation might implement them as LS-wide parameters. > Should they be > defined in both places to support both kinds implementations? > Or should the > spec be interpreted as defining these as LS-wide parameters? [DZ] I think that keeping these parameters in the Peer table would be the best way to go. If the implementation is such that they are globally defined, then the peer entry can use these global values. For this case we should remove tripMinItadOriginationInterval and tripMinRouteAdvertisementInterval from the tripCfgTable because they exist in the Peer table also. > 6) tripLocalAddr: The description should say this is the IP > address of the > local LS that peers connect to. [DZ] Done. > 7) tripLocalPort: The description should say this is the port > on the local > LS that peers connect to. [DZ] Done. > 8) tripSupportedCommunityId: A community ID is not an ITAD. suggest > CommunityID (see issue 4 above). [DZ] Done. > 9) tripPeerEntry: The key consists of only the peer's network type and > address. The spec supports the idea of multiple TRIP > instances on a single > host. The tripPeerRemotePort needs to be included. However, > this is defined > as read-only, which indicates this port is learned when the > connection is > established. If the peer initiated the connection, this may > not be the same > port that the local LS would attempt to connect to. If the > TripPeerIdentifier and TripPeerRemoteItad were configured > parameters, they > could be used as a unique key. However, the > TripPeerIdentifier is read-only > (indicating is learned during the connection), but the > TripPeerRemoteItad is > read-create (indicating it is configured). From reading the > spec, these > could be either configured or learned. [DZ] Both TripPeerIdentifier and TripPeerRemoteItad will be made read-only because either the local application will determine the values, or the values will be learned from the remote end. I agree that tripPeerRemotePort should be part of the index. > I think what is needed is tripRemotePeerPortConfigured (the > port this LS > will try to connect to) to be added to the key. There is not > currently a > field for this. > > 10) tripPeerRemoteItad: Should this be "read-only" ? or should > tripPeerIdentifier be "read-create". I think they should be the same. [DZ] see 9. > 11) tripPeerKeepAlive: The description should indicate that > this is the > negotiated value when a connection is established. [DZ] Done. > 12) tripPeerRouteTypeTable: This table is the expansion table of > tripPeerTable (base table). The DESCRIPTION clause should specify the > relationship of the instances in the base table and expansion > table, when > elements in the expansion table should be added or removed > due to the change > of the base table. This kind of description will be very helpful in > implementing this table, otherwise it will cause confusion and may be > inconsistent with different implementations. > > Same issue for tripRouteCommunityEntry & tripRouteEntry, and > tripItadTopogyIdTable & tripItadTopologyTable. [DZ] Done. > 13) tripRouteTable: It is not totally clear which TRIBs this > table contains. > It says "received routes" which implies it is the > Adj-TRIB-Ins of all peers > (internal & external). However, the presence of > tripRouteAddressOriginatorId > without an originating ITAD would indicate that routes > derived from external > sources inserted into the Ext-TRIB should be included as > opposed to the > received Adj-TRIB-In of the external peer (as they would have > the local LSs > TripID as the OriginatorID). > > Hussein brought up the issue of whether we need a table with > the routes that > the LS will advertise. [DZ] discussed as part of TripRouteTable. > 14) tripRouteAddress: a size of 32 is certainly reasonable for just a > telephone number, but I have heard talk of a number of > different address > families that might involve concatenating things like CIC-code, > carrier-domain or any other kind of so called "routable > element". Would it > hurt to have this be 255 instead? [DZ] Done. > 15) tripRouteEntry: tripRouteAddressOriginatorId should be in the key > instead of tripRoutePeer. A given LS may "learn" several > routes from a peer > where the only distinguishing characteristic of the route is > the Trip ID of > the originating LS. > > same issue for tripRouteCommunityEntry [DZ] A peer will only give it's best route, therefore it will be unique. If the local LS receives the same route from 2 different peers, the originatorId will be the same and the only unique field will be the peer. > 16) tripRouteEntry: you have tripRoutePeer which is the Trip > ID of the LS > that sent the route, but there is not tripRoutePeerITAD to > identify the ITAD > that the peer is in. [DZ] It's in the PeerTable. Do we need to duplicate it in the routeTable, or move it from the PeerTable? > 17) tripRouteAddressOriginatorId should be a TripId instead > of a TripItad. [DZ] Done. > 18) tripBestRoute: I'm not sure what this means. Maybe you > need to identify > the decision process phase in which this is determined. [DZ] This identifies a locTrib. > 19) tripRouteCommunityId: A community ID is not an ITAD. > suggest CommunityID > (see issue 4 above). [DZ] Done. > 20) tripITADTopologyOrigId should be a TripId instead of a TripItad. [DZ] Done. > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > Cheers, DZ --- David Zinman Software Designer SS8 Networks Inc. "One Better" Phone: (613)592-2100 Ext. 3252 Fax: (613)592-9634 mailto:david.zinman@ss8.com http://www.ss8.com ------_=_NextPart_001_01C150D2.56736C66 Content-Type: text/html; charset="iso-8859-1" RE: [IPTEL] Review of draft-ietf-iptel-trip-mib-00.txt

Comments inline.

> -----Original Message-----
> From: Bob Penfield [mailto:bpenfield@acmepacket.com]
> Sent: Friday, September 07, 2001 2:44 PM
> To: IPTEL List
> Cc: Ping Zhou; Ephraim Dobbins; Peter Commerford
> Subject: [IPTEL] Review of draft-ietf-iptel-trip-mib-00.txt
>
>
> We have completed our review of the TRIP MIB and have a
> number of comments
> enumerated below. Special thanks to Ping Zhou, Ephraim
> Dobbins, and Peter
> Commerford for their assistance in this review.
>
> The most significant issue is that of the tripRouteTable. It
> is not clear
> which specific TRIBs it represents. Also, based on some of
> the information
> in the table, it seems to combine data from received and
> derived routes
> (e.g. tripRouteBest) which may prove problematic for implementers. If
> implementers follow the TRIB structure defined in the base
> spec, they may
> need to instantiate another derived/combined TRIB for SNMP reporting.
> Otherwise significant processing/combing of the TRIBs might
> be required to
> respond to a GET. I don't know whether the right thing to do is have a
> separate table for each TRIB or to only report specific sets
> of TRIBs. The
> closest thing to what the table defined represents is the
> Adj-TRIB-Ins of
> internal peers plus the Ext-TRIB derived from local routes
> and Adj-TRIB-Ins
> of external peers. Or am I missing something?
>
[DZ] The TripRouteTable contains information about ALL TRIBS.
However, to get a specific TRIB type, the information must be
extrapolated from the objects within the entry.

Three solutions to this issue: first, use different tables to
represent different TRIBS. For example, we would have a
TripAdjTRIBsInRouteTable, a tripExtTRIBRouteTable, a
tripLocTRIBRouteTable, and a tripAdjTRIBsOutRouteTable. This is
 clumsy in my opinion and would have duplicate entries.

Second, we could use an octet as a mask to signify which TRIB(s) the
entry belongs to. For example
 
tripRouteTRIBMask OBJECT-TYPE
   SYNTAX      OCTET STRING(SIZE(1..255))
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Indicates which TRIB(s) this entry belongs to.
           If the least significant bit is set it would indicate
           that this entry is of type adj-TRIBs-ins. The second
           bit set would indicate ext-TRIB, the third
           loc-TRIB and the fourth adj-TRIB-out.

           0000 0011 would indicate that the entry belongs to
           adj-TRIB-ins and ext-TRIB."
       ::= { tripRouteEntry xx }

Third, we can leave the table as-is and explain better in the table
description what the table represents and how to determine
what TRIB the route is.
 
> 
> 1) Section 4. change "with other TRIP gateways" to "between
> TRIP Location
> Servers".
 
[DZ] Done.
 
> 2) Section 4. change "<draft-ietf-iptel-trip-07-txt>" to "[2]".
 
[DZ] Done.
 
> 3) Section 5 & 5.1. suggest "TRIP LS" instead of "TRIP entity", or add
> "(a.k.a. TRIP LS)".
 
[DZ] Done.
 
> 4) Several places use TripItad for community-id. Community ID
> is not an ITAD
> ID and should be its own type. Suggest adding CommunityId to Textual
> Conventions on page 6.
 
[DZ] Done.
 
> 5) TripCfgEntry: Hussein said that the other timers
> (ConnectRetry, HoldTime,
> KeepAlive) belong here. The spec does not explicitly say
> whether these are
> configured for the LS (like SendReceiveMode) or on a per-peer
> basis. The MIB
> defines them as per-peer parameters (in TripPeerEntry).
> However, a given
> implementation might implement them as LS-wide parameters.
> Should they be
> defined in both places to support both kinds implementations?
> Or should the
> spec be interpreted as defining these as LS-wide parameters?
 
[DZ] I think that keeping these parameters in the Peer table
would be the best way to go. If the implementation is such that
they are globally defined, then the peer entry can use these
global values. For this case we should remove
tripMinItadOriginationInterval and
tripMinRouteAdvertisementInterval from the tripCfgTable because
they exist in the Peer table also.
 
 
> 6) tripLocalAddr: The description should say this is the IP
> address of the
> local LS that peers connect to.
 
[DZ] Done.
 
> 7) tripLocalPort: The description should say this is the port
> on the local
> LS that peers connect to.
 
[DZ] Done.
 
> 8) tripSupportedCommunityId: A community ID is not an ITAD. suggest
> CommunityID (see issue 4 above).
 
[DZ] Done.
 
> 9) tripPeerEntry: The key consists of only the peer's network type and
> address. The spec supports the idea of multiple TRIP
> instances on a single
> host. The tripPeerRemotePort needs to be included. However,
> this is defined
> as read-only, which indicates this port is learned when the
> connection is
> established. If the peer initiated the connection, this may
> not be the same
> port that the local LS would attempt to connect to. If the
> TripPeerIdentifier and TripPeerRemoteItad were configured
> parameters, they
> could be used as a unique key. However, the
> TripPeerIdentifier is read-only
> (indicating is learned during the connection), but the
> TripPeerRemoteItad is
> read-create (indicating it is configured). From reading the
> spec, these
> could be either configured or learned.
 
[DZ] Both TripPeerIdentifier and TripPeerRemoteItad will be
made read-only because either the local application will
determine the values, or the values will be learned from the
remote end. I agree that tripPeerRemotePort should be part
of the index.
 
> I think what is needed is tripRemotePeerPortConfigured (the
> port this LS
> will try to connect to) to be added to the key. There is not
> currently a
> field for this.
>
> 10) tripPeerRemoteItad: Should this be "read-only" ? or should
> tripPeerIdentifier be "read-create". I think they should be the same.
 
[DZ] see 9.
 
> 11) tripPeerKeepAlive: The description should indicate that
> this is the
> negotiated value when a connection is established.
 
[DZ] Done.
 
> 12) tripPeerRouteTypeTable: This table is the expansion table of
> tripPeerTable  (base table). The DESCRIPTION clause should specify the
> relationship of the instances in the base table and expansion
> table, when
> elements in the expansion table should be added or removed
> due to the change
> of the base table. This kind of description will be very helpful in
> implementing this table, otherwise it will cause confusion and may be
> inconsistent with different implementations.
>
> Same issue for tripRouteCommunityEntry & tripRouteEntry, and
> tripItadTopogyIdTable & tripItadTopologyTable.
 
[DZ] Done.
 
> 13) tripRouteTable: It is not totally clear which TRIBs this
> table contains.
> It says "received routes" which implies it is the
> Adj-TRIB-Ins of all peers
> (internal & external). However, the presence of
> tripRouteAddressOriginatorId
> without an originating ITAD would indicate that routes
> derived from external
> sources inserted into the Ext-TRIB should be included as
> opposed to the
> received Adj-TRIB-In of the external peer (as they would have
> the local LSs
> TripID as the OriginatorID).
>
> Hussein brought up the issue of whether we need a table with
> the routes that
> the LS will advertise.
 
[DZ] discussed as part of TripRouteTable.
 
> 14) tripRouteAddress: a size of 32 is certainly reasonable for just a
> telephone number, but I have heard talk of a number of
> different address
> families that might involve concatenating things like CIC-code,
> carrier-domain or any other kind of so called "routable
> element". Would it
> hurt to have this be 255 instead?
 
[DZ] Done.
 
> 15) tripRouteEntry: tripRouteAddressOriginatorId should be in the key
> instead of tripRoutePeer. A given LS may "learn" several
> routes from a peer
> where the only distinguishing characteristic of the route is
> the Trip ID of
> the originating LS.
>
> same issue for tripRouteCommunityEntry
 
[DZ] A peer will only give it's best route, therefore it will
be unique. If the local LS receives the same route from 2
different peers, the originatorId will be the same and the
only unique field will be the peer.
 
> 16) tripRouteEntry: you have tripRoutePeer which is the Trip
> ID of the LS
> that sent the route, but there is not tripRoutePeerITAD to
> identify the ITAD
> that the peer is in.
 
[DZ] It's in the PeerTable. Do we need to duplicate it in the
routeTable, or move it from the PeerTable?
 
> 17) tripRouteAddressOriginatorId should be a TripId instead
> of a TripItad.
 
[DZ] Done.
 
> 18) tripBestRoute: I'm not sure what this means. Maybe you
> need to identify
> the decision process phase in which this is determined.
 
[DZ] This identifies a locTrib.
 
> 19) tripRouteCommunityId: A community ID is not an ITAD.
> suggest CommunityID
> (see issue 4 above).
 
[DZ] Done.
 
> 20) tripITADTopologyOrigId should be a TripId instead of a TripItad.
 
[DZ] Done.
 
> (-:bob
>
> Robert F. Penfield
> Chief Software Architect
> Acme Packet, Inc.
> 130 New Boston Street
> Woburn, MA 01801
> bpenfield@acmepacket.com
>
 
 
Cheers,
 DZ
 
---
David Zinman    Software Designer
SS8 Networks Inc. "One Better"
Phone: (613)592-2100 Ext. 3252
Fax: (613)592-9634
mailto:david.zinman@ss8.com
http://www.ss8.com
 
 

------_=_NextPart_001_01C150D2.56736C66-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Oct 10 13:22:36 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15537 for ; Wed, 10 Oct 2001 13:22:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1A51D4433B; Wed, 10 Oct 2001 12:18:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from znsgs0ja.europe.nortel.com (unknown [47.165.25.40]) by lists.bell-labs.com (Postfix) with ESMTP id 8626A44336 for ; Wed, 10 Oct 2001 12:17:17 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f9AHLWg03518 for ; Wed, 10 Oct 2001 18:21:32 +0100 (BST) Received: from nwcwi1a.europe.nortel.com by znsgs016; Wed, 10 Oct 2001 18:18:50 +0100 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <44J0RYJ4>; Wed, 10 Oct 2001 18:18:24 +0100 Message-ID: <588B15E2E2B1D41180B800508BF934F251ECF9@bmdhd6.europe.nortel.com> From: "William Parton" To: "'iptel@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C151AF.9056AA50" Subject: [IPTEL] Path Aggregation 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 10 Oct 2001 18:18:22 +0100 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_01C151AF.9056AA50 Content-Type: text/plain; charset="iso-8859-1" I'm trying to get to grips with Path aggregation and, being unfamiliar with BGP, I'd like to check my understanding with someone knowledgeable in this area (I couldn't find any discussion in the IPTEL mailing list). The TRIP spec gives an example path aggregation algorithm in 5.4.4.3: An example algorithm to aggregate two paths works as follows: (A)- Identify the ITADs (as defined in Section 5.4.1) within each path attribute that are in the same relative order within both path attributes. Two ITADs, X and Y, are said to be in the same order if either X precedes Y in both paths, or if Y precedes X in both paths. (B)- The aggregated path consists of ITADs identified in (a) in exactly the same order as they appear in the paths to be aggregated. If two consecutive ITADs identified in (a) do not immediately follow each other in both of the paths to be aggregated, then the intervening ITADs (ITADs that are between the two consecutive ITADs that are the same) in both attributes are combined into an AP_SET path segment that consists of the intervening ITADs from both paths; this segment is then placed in between the two consecutive ITADs identified in (a) of the aggregated attribute. If two consecutive ITADs identified in (a) immediately follow each other in one attribute, but do not follow in another, then the intervening ITADs of the latter are combined into an AP_SET path segment; this segment is then placed in between the two consecutive ITADs identified in (a) of the aggregated path. If as a result of the above procedure a given ITAD number appears more than once within the aggregated path, all, but the last instance (rightmost occurrence) of that ITAD number should be removed from the aggregated path. Running this algorithm over two example Paths: Pa = AP_SEQ[x1, x2, x3] AP_SET[x4, x5] AP_SEQ[x6, x7, x8] Pb = AP_SET[x1, x2] AP_SEQ[x4, x7] From my reading of step (A) the AP_SET or AP_SEQUENCE associated with an ITAD ID is ignored, it is the relative order that matters (correct?). If this is true can I not legitimately rewrite AP_SET[x4, x5] as AP_SET[x5, x4] and perhaps gain some benefit in step (B). This produces four ITAD IDs with the same relative order in both Pa and Pb => x1, x2, x4, x7 The resultant aggregated Path from step (B) then becomes Pagg = AP_SEQ[x1, x2] AP_SET[x3] AP_SEQ[x4] AP_SET[x5, x6] AP_SEQ[x7] AP_SET[x8] - Am I interpreting the algorithm correctly? - Are the singleton sets and sequences that result correct? - Is the allocation of AP_SET and AP_SEQ in Pagg correct? - Is a singleton sequence meaningless and could (should?) the sequence AP_SET[x3] AP_SEQ[x4] AP_SET[x5, x6] AP_SEQ[x7] AP_SET[x8] be replaced by AP_SET[x3, x4, x5, x6, x7, x8] without any loss of information? Will ------_=_NextPart_001_01C151AF.9056AA50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Path Aggregation

I'm trying to get to grips with Path aggregation and, = being unfamiliar with BGP, I'd like to check my understanding with = someone knowledgeable in this area (I couldn't find any discussion in = the IPTEL mailing list).

The TRIP spec gives an example path aggregation = algorithm in 5.4.4.3:

An example algorithm to aggregate two paths works as = follows:
(A)- Identify the ITADs (as defined in Section = 5.4.1) within each path attribute that are in the same relative order = within both path attributes. Two ITADs, X and Y, are said to be in the = same order if either X precedes Y in both paths, or if Y precedes X in = both paths.

(B)- The aggregated path consists of ITADs identified = in (a) in exactly the same order as they appear in the paths to be = aggregated. If two consecutive ITADs identified in (a) do not = immediately follow each other in both of the paths to be aggregated, = then the intervening ITADs (ITADs that are between the two consecutive = ITADs that are the same) in both attributes are combined into an AP_SET = path segment that consists of the intervening ITADs from both paths; = this segment is then placed in between the two consecutive ITADs = identified in (a) of the aggregated attribute. If two consecutive ITADs = identified in (a) immediately follow each other in one attribute, but = do not follow in another, then the intervening ITADs of the latter are = combined into an AP_SET path segment; this segment is then placed in = between the two consecutive ITADs identified in (a) of the aggregated = path.

If as a result of the above procedure a given ITAD = number appears more than once within the aggregated path, all, but the = last instance (rightmost occurrence) of that ITAD number should be = removed from the aggregated path.

Running this algorithm over two example Paths:
Pa =3D AP_SEQ[x1, x2, x3] AP_SET[x4, x5] AP_SEQ[x6, = x7, x8]
Pb =3D AP_SET[x1, x2] AP_SEQ[x4, x7]

From my reading of step (A) the AP_SET or AP_SEQUENCE = associated with an ITAD ID is ignored, it is the relative order that = matters (correct?). If this is true can I not legitimately rewrite = AP_SET[x4, x5] as AP_SET[x5, x4] and perhaps gain some benefit in step = (B).

This produces four ITAD IDs with the same relative = order in both Pa and Pb =3D> x1, x2, x4, x7

The resultant aggregated Path from step (B) then = becomes
Pagg =3D AP_SEQ[x1, x2] AP_SET[x3] AP_SEQ[x4] = AP_SET[x5, x6] AP_SEQ[x7] AP_SET[x8]

- Am I interpreting the algorithm correctly?
- Are the singleton sets and sequences that result = correct?
- Is the allocation of AP_SET and AP_SEQ in Pagg = correct?
- Is a singleton sequence meaningless and could = (should?) the sequence
AP_SET[x3] AP_SEQ[x4] AP_SET[x5, x6] AP_SEQ[x7] = AP_SET[x8]
be replaced by AP_SET[x3, x4, x5, x6, x7, x8] = without any loss of information?



Will

------_=_NextPart_001_01C151AF.9056AA50-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From anony@solo.com Mon Oct 15 04:29:45 2001 Received: from smtp.prodigy.net.mx ([148.235.168.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22082 for ; Mon, 15 Oct 2001 04:29:45 -0400 (EDT) Received: from dismamex (du-148-233-91-245.prodigy.net.mx [148.233.91.245]) by SMTP.Prodigy.Net.mx (Sun Internet Mail Server sims.4.0.2001.07.26.11.50.p9) with SMTP id <0GL800AVHMHTX5@SMTP.Prodigy.Net.mx>; Mon, 15 Oct 2001 02:27:32 -0600 (CST) Date: Mon, 15 Oct 2001 02:27:07 -0600 From: Mercedes Flores Castaneda Subject: 20 DE OCTUBRE, SEMINARIO SERVICIO AL CLIENTE, CUPO LIMITADO To: iptel-archive@ietf.org Reply-to: consulem2000@yahoo.com.mx Message-id: <0GL800A9NNHMX5@SMTP.Prodigy.Net.mx> MIME-version: 1.0 X-Mailer: Mailer Signature Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 8BIT Content-Transfer-Encoding: 8BIT SEMINARIO COMO INCREMENTAR LAS VENTAS A TRAVES DEL SERVICIO TEMARIO: 1. Qué es realmente el servicio al cliente? 2. Errores que se deben evitar al dar atencion y servicio al cliente. 3. Cómo afecta a la empresa un cliente descontento? 4. Como manejar a un cliente inconforme. 5. Como establecer una excelente relacion con el cliente. 6. Eficiencia en la entrega del servicio. 7. Velocidad de servicio. 8. Como incrementar los ingresos de la empresa mediante un excelente servicio. 9. Profesionalismo en la atencion y servicio al cliente. 10. Ejercicios practicos dirigidos a la aplicación de las tecnicas y conocimientos aprendidos. Fecha: 20 de Octubre Lugar: Hotel Bristol, Salon Bristol, Plaza Necaxa No. 17 Rio Panuco esq. Rio Sena, Col. Cuauhtemoc, D.F. Duracion: 8 horas, 50% del tiempo se dedica a la realizacion de ejercicios practicos. Horario: Registro 8:30 a.m. Seminario de las 9:00 a.m. a las 6:30 p.m. Dirigido a: Ejecutivos de ventas, vendedores y propietarios de negocios. Inversion: $1,900.00 por participante (más I.V.A.) Incluye: Material de apoyo, coffee breaks y comida. Conferencista Internacional: Lic. Ricardo Colin Morales Con más de 20 años de experiencia capacitando a miles de vendedores para la industria. RESERVE SUS LUGARES HOY MISMO TELS. 55 43 59 61 Y 55 43 57 81 CON LA LIC. MERCEDES FLORES CASTAÑEDA DIRECTORA DE RELACIONES PUBLICAS CONSULTORIA EMPRESARIAL P.D. Conforme a las leyes nacionales como internacionales este e-mail no puede ser considerado como SPAM, incluye un procedimiento para ser removido de la lista. Si desea ser removido envienos un e-mail a ricolin2002@yahoo.com.mx, indicandonos a que correo le hemos contactado y en el asunto indique el mail que desea remover ejemplo: Asunto : tigre26mx@yahoo.com Gracias From iptel-admin@lists.bell-labs.com Wed Oct 17 02:49:27 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13960 for ; Wed, 17 Oct 2001 02:49:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 23E1644337; Wed, 17 Oct 2001 01:44:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 65CC444336 for ; Wed, 17 Oct 2001 01:43:21 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9H6mnk22516; Tue, 16 Oct 2001 23:48:49 -0700 (PDT) Received: from cisco.com (sjc-vpn-267.cisco.com [10.21.65.11]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AAM08936; Tue, 16 Oct 2001 23:48:41 -0700 (PDT) Message-ID: <3BCD2A00.9CBF26B3@cisco.com> From: Manjunath Bangalore X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: William Parton Cc: "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] Path Aggregation References: <588B15E2E2B1D41180B800508BF934F251ECF9@bmdhd6.europe.nortel.com> Content-Type: text/plain; charset=us-ascii 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 16 Oct 2001 23:49:36 -0700 Content-Transfer-Encoding: 7bit Hi William, Please refer inline - William Parton wrote: > > > I'm trying to get to grips with Path aggregation and, being unfamiliar > with BGP, I'd like to check my understanding with someone > knowledgeable in this area (I couldn't find any discussion in the > IPTEL mailing list). > > The TRIP spec gives an example path aggregation algorithm in 5.4.4.3: > > An example algorithm to aggregate two paths works as follows: > (A)- Identify the ITADs (as defined in Section 5.4.1) within each path > attribute that are in the same relative order within both path > attributes. Two ITADs, X and Y, are said to be in the same order if > either X precedes Y in both paths, or if Y precedes X in both paths. > > (B)- The aggregated path consists of ITADs identified in (a) in > exactly the same order as they appear in the paths to be aggregated. > If two consecutive ITADs identified in (a) do not immediately follow > each other in both of the paths to be aggregated, then the intervening > ITADs (ITADs that are between the two consecutive ITADs that are the > same) in both attributes are combined into an AP_SET path segment that > consists of the intervening ITADs from both paths; this segment is > then placed in between the two consecutive ITADs identified in (a) of > the aggregated attribute. If two consecutive ITADs identified in (a) > immediately follow each other in one attribute, but do not follow in > another, then the intervening ITADs of the latter are combined into an > AP_SET path segment; this segment is then placed in between the two > consecutive ITADs identified in (a) of the aggregated path. > > If as a result of the above procedure a given ITAD number appears more > than once within the aggregated path, all, but the last instance > (rightmost occurrence) of that ITAD number should be removed from the > aggregated path. > > Running this algorithm over two example Paths: > Pa = AP_SEQ[x1, x2, x3] AP_SET[x4, x5] AP_SEQ[x6, x7, x8] > Pb = AP_SET[x1, x2] AP_SEQ[x4, x7] > [Manjax] Firstly, the path Pb is inconsistent for the following reason: The AP_SET in Pb shouldn't appear at the beginning of the AdvertisementPath but the neighbor's ITAD from whom the route was learnt should be at the beginning So, let us say, I modify the AdvertisementPaths to the following: Pa = AP_SEQ[x0, x1, x2, x3] AP_SET[x4, x5] AP_SEQ[x6, x7, x8] Pb = AP_SEQ[x0] AP_SET[x1, x2] AP_SEQ[x4, x7] > > From my reading of step (A) the AP_SET or AP_SEQUENCE associated with > an ITAD ID is ignored, it is the relative order that matters > (correct?). If this is true can I not legitimately rewrite AP_SET[x4, > x5] as AP_SET[x5, x4] and perhaps gain some benefit in step (B). > [Manjax] I think the type is important, it has to be considered for correctness. The definition in step (A) refers to section 5.4.1 for identifying ITADs where definition of an ITAD encompasses the type but I feel the text matter in step (A) should be made more explicit to point out consideration of the type > > This produces four ITAD IDs with the same relative order in both Pa > and Pb => x1, x2, x4, x7 > [Manjax] With that, step (A) gives us: x0 x7 > > The resultant aggregated Path from step (B) then becomes > Pagg = AP_SEQ[x1, x2] AP_SET[x3] AP_SEQ[x4] AP_SET[x5, x6] AP_SEQ[x7] > AP_SET[x8] [Manjax] From Step B, we have: Pagg = AP_SEQ[x0] AP_SET[x1, x2, x3, x4, x5, x6] AP_SEQ[x7] AP_SET[x8] > > - Am I interpreting the algorithm correctly? > - Are the singleton sets and sequences that result correct? > [Manjax] For singleton path segments, AP_SETs or AP_SEQs are okay > - Is the allocation of AP_SET and AP_SEQ in Pagg correct? > > - Is a singleton sequence meaningless and could (should?) the sequence > > AP_SET[x3] AP_SEQ[x4] AP_SET[x5, x6] AP_SEQ[x7] AP_SET[x8] > be replaced by AP_SET[x3, x4, x5, x6, x7, x8] without any loss of > information? > [Manjax] It is not meaningless, because there is an implicit relative ordering between the different path segments; in this case an AP_SET would result in loss of information From sec 10.3.4.1, An AP_SET implies that the destinations advertised in the UPDATE message can be reached through paths that traverse at least some of the constituent ITADs. The example path AP_SEQ[x4] AP_SET[x5, x6] AP_SEQ[x7] represents two possible "real" paths : x4, x5, x7 and x4, x6, x7. This information would be lost if just an AP_SET was advertised. --Manjax > > > Will _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Oct 19 14:33:47 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27312 for ; Fri, 19 Oct 2001 14:33:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E9A1744344; Fri, 19 Oct 2001 13:28:01 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 385874433E for ; Fri, 19 Oct 2001 13:27:23 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9JIXBU15550 for ; Fri, 19 Oct 2001 11:33:12 -0700 (PDT) Received: from cj14 (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ABE65479; Fri, 19 Oct 2001 11:33:06 -0700 (PDT) From: "Cullen Jennings" To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Subject: [IPTEL] Requirement relating to multicast 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 19 Oct 2001 11:39:03 -0700 Content-Transfer-Encoding: 7bit I think it should be a requirement of the GW to LS protocol that it does not require multicast. I can imagine scenarios where the size of the ITAD on the network was larger than the space on the network where multicast would route. Cullen _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Oct 19 14:35:28 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27384 for ; Fri, 19 Oct 2001 14:35:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F117E44354; Fri, 19 Oct 2001 13:28:05 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 54E2744344 for ; Fri, 19 Oct 2001 13:27:23 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9JIXCU15555 for ; Fri, 19 Oct 2001 11:33:12 -0700 (PDT) Received: from cj14 (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ABE65480; Fri, 19 Oct 2001 11:33:06 -0700 (PDT) From: "Cullen Jennings" To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Subject: [IPTEL] GW knowing the cost of calls 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 19 Oct 2001 11:39:03 -0700 Content-Transfer-Encoding: 7bit The GW should not need to know the cost of any given route in Columbia Laundry Tokens or any other currency. It changes too quickly and the GW are a very difficult place to update it. Let's avoid this path. Cullen _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Oct 19 14:37:54 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27470 for ; Fri, 19 Oct 2001 14:37:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6C4A744359; Fri, 19 Oct 2001 13:28:09 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id A5CF344348 for ; Fri, 19 Oct 2001 13:27:23 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9JIXCU15560 for ; Fri, 19 Oct 2001 11:33:12 -0700 (PDT) Received: from cj14 (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ABE65481; Fri, 19 Oct 2001 11:33:07 -0700 (PDT) From: "Cullen Jennings" To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 5 (Lowest) X-MSMail-Priority: Low X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Low Subject: [IPTEL] How many protocols do I need to implement 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 19 Oct 2001 11:39:04 -0700 Content-Transfer-Encoding: 7bit The LS is going to need TRIP to do the ITRIP and ETRIP type stuff. I am hopeful that I can just tweak this code a bit and not add yet another protocol to get information from the GW. If we add a completely different protocol, with a different way of representing attributes, I feel that it will significantly up the issues of 1) defining correct mapping between this protocol and I/E TRIP. 2) up development and particularly test. Similarly, the GW will may need to act like a LS and do ITRIP for cases where there is no LS in the network. If SLP is clearly better and provides some other things - great but if it just an alternative to TRIP, well I am worried I will now have to do both instead of just one. Cullen _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Oct 19 14:59:48 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28006 for ; Fri, 19 Oct 2001 14:59:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B2C034435D; Fri, 19 Oct 2001 13:54:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from integraonline.com (web-2-bvtn.integraonline.com [206.163.82.91]) by lists.bell-labs.com (Postfix) with SMTP id 45FC944352 for ; Fri, 19 Oct 2001 13:53:32 -0400 (EDT) Received: (qmail 17117 invoked from network); 19 Oct 2001 18:59:19 -0000 Received: from fw-1-bvtn.integratelecom.com (HELO beaexch2.ads.integratelecom.com) ([206.163.82.5]) (envelope-sender ) by web-2-bvtn.integraonline.com (qmail-ldap-1.03) with SMTP for ; 19 Oct 2001 18:59:19 -0000 Received: by beaexch2.ads.integratelecom.com with Internet Mail Service (5.5.2650.21) id ; Fri, 19 Oct 2001 11:59:16 -0700 Message-ID: From: "Anderson, Darby" To: "'Cullen Jennings'" , iptel@lists.bell-labs.com Subject: RE: [IPTEL] GW knowing the cost of calls MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 19 Oct 2001 11:59:15 -0700 When you say that a G/W doesnt need to know "a" cost of a call, you mean the G/W on the TERMINATION leg of the call, correct? -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Friday, October 19, 2001 12:39 PM To: iptel@lists.bell-labs.com Subject: [IPTEL] GW knowing the cost of calls The GW should not need to know the cost of any given route in Columbia Laundry Tokens or any other currency. It changes too quickly and the GW are a very difficult place to update it. Let's avoid this path. Cullen _______________________________________________ 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 Oct 19 15:13:47 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28406 for ; Fri, 19 Oct 2001 15:13:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 386A644363; Fri, 19 Oct 2001 14:08:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from Mitel.COM (unknown [216.191.234.70]) by lists.bell-labs.com (Postfix) with ESMTP id 802854435E for ; Fri, 19 Oct 2001 14:07:49 -0400 (EDT) Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id PAA11889; Fri, 19 Oct 2001 15:11:30 -0400 (EDT) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256AEA.0069627A ; Fri, 19 Oct 2001 15:11:04 -0400 X-Lotus-FromDomain: MITEL From: Tom_Gray@Mitel.COM To: "Anderson, Darby" Cc: "'Cullen Jennings'" , iptel@lists.bell-labs.com Message-ID: <85256AEA.00696251.00@kanmta01.software.mitel.com> Subject: RE: [IPTEL] GW knowing the cost of calls Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 19 Oct 2001 15:13:51 -0400 From: Tom Gray@MITEL on 10/19/2001 03:13 PM What sort of route selection policies belong in the gateway? Recall that some routes will be more expensive than others in terms of real money. "Anderson, Darby" on 10/19/2001 02:59:15 PM To: "'Cullen Jennings'" , iptel@lists.bell-labs.com cc: (bcc: Tom Gray/Kan/Mitel) Subject: RE: [IPTEL] GW knowing the cost of calls When you say that a G/W doesnt need to know "a" cost of a call, you mean the G/W on the TERMINATION leg of the call, correct? -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Friday, October 19, 2001 12:39 PM To: iptel@lists.bell-labs.com Subject: [IPTEL] GW knowing the cost of calls The GW should not need to know the cost of any given route in Columbia Laundry Tokens or any other currency. It changes too quickly and the GW are a very difficult place to update it. Let's avoid this path. Cullen _______________________________________________ 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 Fri Oct 19 15:54:46 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29671 for ; Fri, 19 Oct 2001 15:54:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6743444350; Fri, 19 Oct 2001 14:49:01 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1.email.verio.net [129.250.36.41]) by lists.bell-labs.com (Postfix) with ESMTP id D7A9D4433E for ; Fri, 19 Oct 2001 14:48:07 -0400 (EDT) Received: from [129.250.38.63] (helo=dfw-mmp3.email.verio.net) by dfw-smtpout1.email.verio.net with esmtp id 15ufiF-0003nu-00 for iptel@lists.bell-labs.com; Fri, 19 Oct 2001 19:53:47 +0000 Received: from [63.180.67.31] (helo=TELXXIS.telxxis.com) by dfw-mmp3.email.verio.net with esmtp id 15ufiE-0000E1-00; Fri, 19 Oct 2001 19:53:47 +0000 Message-Id: <5.1.0.14.0.20011019125345.02de3848@mail.ncal.verio.net> X-Sender: brennan@mail.ncal.verio.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: iptel@lists.bell-labs.com From: Richard Brennan Subject: Re: [IPTEL] GW knowing the cost of calls Cc: 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 19 Oct 2001 12:53:54 -0700 Wholeheartedly agree... And that's why policy-based Back-End Servers (BES) were invented... so that each network element would NOT have to be provisioned in real-time with constantly changing destination location and cost (price? currency? units?...whatever) information... Richard At 11:39 AM 10/19/2001, Cullen Jennings wrote: >The GW should not need to know the cost of any given route in Columbia >Laundry Tokens or any other currency. It changes too quickly and the GW are >a very difficult place to update it. Let's avoid this path. > >Cullen _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Oct 19 16:58:46 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01317 for ; Fri, 19 Oct 2001 16:58:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 05D4744353; Fri, 19 Oct 2001 15:53:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by lists.bell-labs.com (Postfix) with ESMTP id 4910C4433E for ; Fri, 19 Oct 2001 15:52:42 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f9JKuGa20625 for ; Fri, 19 Oct 2001 13:56:17 -0700 (PDT) Received: from cj14 (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ABE69268; Fri, 19 Oct 2001 13:58:23 -0700 (PDT) From: "Cullen Jennings" To: Subject: RE: [IPTEL] GW knowing the cost of calls Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Importance: Normal 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 19 Oct 2001 14:04:20 -0700 Content-Transfer-Encoding: 7bit Ah yes, I should have been more careful on what I said. I think having a terminating gateway export via some protocol a route like "I can reach all numbers of the form +1408* and it costs my 0.04 US dollars per minute plus a setup charge" is a bad idea. Clearly least cost routing is a hugely important part of what we are trying to accomplish in VoIP but having the GW need to know the cost of the route is the wrong way to do it. Providing information that can be correlated with a billing rating engine like "I can reach numbers of the form +1408* using a trunk connected to Sprint in the +1 408 263 exchange" seems like a more practical way to implement least cost routing. Something in the core of the network that is capable of least cost routing decisions is an easier place to update this constantly changing price information than the edge GW. Keep in mind people will often buy a block of minutes from some carrier and once they have used up those minutes the rate will change dramatically. So you have to keep track of the number of minutes used by all your GW, not just one, to that carrier to accurately know what the next call to a given trunk might cost. If we are talking about an initiating GW instead of a terminating GW, the carrier it came from and ANI may be important for routing decisions but I don't see if having much to do with TRIP. Cullen -----Original Message----- From: Anderson, Darby [mailto:Darby.Anderson@integratelecom.com] Sent: Friday, October 19, 2001 11:59 AM To: 'Cullen Jennings'; iptel@lists.bell-labs.com Subject: RE: [IPTEL] GW knowing the cost of calls When you say that a G/W doesnt need to know "a" cost of a call, you mean the G/W on the TERMINATION leg of the call, correct? -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Friday, October 19, 2001 12:39 PM To: iptel@lists.bell-labs.com Subject: [IPTEL] GW knowing the cost of calls The GW should not need to know the cost of any given route in Columbia Laundry Tokens or any other currency. It changes too quickly and the GW are a very difficult place to update it. Let's avoid this path. Cullen _______________________________________________ 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 Oct 19 18:09:47 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02879 for ; Fri, 19 Oct 2001 18:09:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2E6AA44366; Fri, 19 Oct 2001 17:04:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from face.sentitonetworks.com (user9.sentito.com [65.202.222.9]) by lists.bell-labs.com (Postfix) with SMTP id CAE484433E for ; Fri, 19 Oct 2001 17:03:43 -0400 (EDT) Received: (qmail 13162 invoked from network); 19 Oct 2001 22:03:14 -0000 Received: from unknown (HELO SAJAK) (65.202.222.2) by face.sentitonetworks.com with SMTP; 19 Oct 2001 22:03:14 -0000 From: "Shan Lu" To: "'Cullen Jennings'" , Subject: RE: [IPTEL] GW knowing the cost of calls Message-ID: <000801c158ea$b3b771e0$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 19 Oct 2001 18:09:20 -0400 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: iptel-admin@lists.bell-labs.com > [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of Cullen Jennings > Sent: Friday, October 19, 2001 5:04 PM > To: iptel@lists.bell-labs.com > Subject: RE: [IPTEL] GW knowing the cost of calls > > Ah yes, I should have been more careful on what I said. > > I think having a terminating gateway export via some protocol > a route like > "I can reach all numbers of the form +1408* and it costs my > 0.04 US dollars > per minute plus a setup charge" is a bad idea. Clearly least Just want to clarify that having a GW export all the numbers it can terminate is actually a very useful feature. For example, a gateway may have media trunks to certain end exchanges that are identified by NPA-NXX. Then the gateway will need to export this information out, like "I can terminate all calls starting with +1-301-222". Shan Lu _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Oct 19 18:50:46 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04111 for ; Fri, 19 Oct 2001 18:50:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E2E9D4436E; Fri, 19 Oct 2001 17:45:01 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from integraonline.com (web-1-bvtn.integraonline.com [206.163.82.90]) by lists.bell-labs.com (Postfix) with SMTP id 909D24436C for ; Fri, 19 Oct 2001 17:44:53 -0400 (EDT) Received: (qmail 265 invoked from network); 19 Oct 2001 22:50:42 -0000 Received: from fw-1-bvtn.integratelecom.com (HELO beaexch2.ads.integratelecom.com) ([206.163.82.5]) (envelope-sender ) by web-1-bvtn.integraonline.com (qmail-ldap-1.03) with SMTP for ; 19 Oct 2001 22:50:42 -0000 Received: by beaexch2.ads.integratelecom.com with Internet Mail Service (5.5.2650.21) id ; Fri, 19 Oct 2001 15:50:38 -0700 Message-ID: From: "Anderson, Darby" To: "'Cullen Jennings'" , iptel@lists.bell-labs.com Subject: RE: [IPTEL] GW knowing the cost of calls MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 19 Oct 2001 15:50:38 -0700 I suppose now would be a good time to clarify this in my mind, someone please correct me if Im wrong... In the TRIP architecture, wouldent (an) ITAD have one or more "Soft switches" if you will (RouteServ) with similarly paired redundancy relationships as occurs in SCP/STP/SP Relationships, where in which all of the destination,trunking,routing,costing/charging occurs, which then regionally feeds down to a Proxy (LocServ), as to make kinda a cache for thoose routing decisions, which in turn filters down to the G/W's which actually process the voice trunking?? or do I need to drink some more beer? lol -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Friday, October 19, 2001 3:04 PM To: iptel@lists.bell-labs.com Subject: RE: [IPTEL] GW knowing the cost of calls Ah yes, I should have been more careful on what I said. I think having a terminating gateway export via some protocol a route like "I can reach all numbers of the form +1408* and it costs my 0.04 US dollars per minute plus a setup charge" is a bad idea. Clearly least cost routing is a hugely important part of what we are trying to accomplish in VoIP but having the GW need to know the cost of the route is the wrong way to do it. Providing information that can be correlated with a billing rating engine like "I can reach numbers of the form +1408* using a trunk connected to Sprint in the +1 408 263 exchange" seems like a more practical way to implement least cost routing. Something in the core of the network that is capable of least cost routing decisions is an easier place to update this constantly changing price information than the edge GW. Keep in mind people will often buy a block of minutes from some carrier and once they have used up those minutes the rate will change dramatically. So you have to keep track of the number of minutes used by all your GW, not just one, to that carrier to accurately know what the next call to a given trunk might cost. If we are talking about an initiating GW instead of a terminating GW, the carrier it came from and ANI may be important for routing decisions but I don't see if having much to do with TRIP. Cullen -----Original Message----- From: Anderson, Darby [mailto:Darby.Anderson@integratelecom.com] Sent: Friday, October 19, 2001 11:59 AM To: 'Cullen Jennings'; iptel@lists.bell-labs.com Subject: RE: [IPTEL] GW knowing the cost of calls When you say that a G/W doesnt need to know "a" cost of a call, you mean the G/W on the TERMINATION leg of the call, correct? -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Friday, October 19, 2001 12:39 PM To: iptel@lists.bell-labs.com Subject: [IPTEL] GW knowing the cost of calls The GW should not need to know the cost of any given route in Columbia Laundry Tokens or any other currency. It changes too quickly and the GW are a very difficult place to update it. Let's avoid this path. Cullen _______________________________________________ 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 Fri Oct 19 21:55:50 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12183 for ; Fri, 19 Oct 2001 21:55:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6A1014436C; Fri, 19 Oct 2001 20:50:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id ADACD4433E for ; Fri, 19 Oct 2001 20:49:50 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f9K1tO329727; Fri, 19 Oct 2001 21:55:24 -0400 (EDT) Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id VAA01019; Fri, 19 Oct 2001 21:54:04 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Oct 2001 21:55:23 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: Cullen Jennings , iptel@lists.bell-labs.com Subject: RE: [IPTEL] Requirement relating to multicast MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 19 Oct 2001 21:55:22 -0400 Cullen: Please see my comments below [RRR]. Radhika From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Friday, October 19, 2001 2:39 PM I think it should be a requirement of the GW to LS protocol that it does not require multicast. [RRR] How does one to make discovery? Are you suggesting pre-provisioning? Or, do you like to use DNS stuff-like things where the list of LSs or GWs to be provided? I can imagine scenarios where the size of the ITAD on the network was larger than the space on the network where multicast would route. [RRR] Yes, you are right especially in the case of intra-ITAD. That is why, in the draft (draft-roy-sipproxy-ls-gw-discovery-00.txt), alternative schemes to multicasting for discovery have been proposed. We do not need either a heavy-weight discovery mechanism or a very elaborate scheme for multicasting for the intra-ITAD. [RRR] More discussion along this will be posted soon. Cullen _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Oct 19 22:09:49 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12712 for ; Fri, 19 Oct 2001 22:09:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DB97A44375; Fri, 19 Oct 2001 21:04:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 2FEDB4433E for ; Fri, 19 Oct 2001 21:03:29 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f9K29D307783 for ; Fri, 19 Oct 2001 22:09:14 -0400 (EDT) Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id VAA01019; Fri, 19 Oct 2001 21:54:04 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Oct 2001 21:55:23 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: Cullen Jennings , iptel@lists.bell-labs.com Subject: RE: [IPTEL] Requirement relating to multicast MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 19 Oct 2001 21:55:22 -0400 Cullen: Please see my comments below [RRR]. Radhika From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Friday, October 19, 2001 2:39 PM I think it should be a requirement of the GW to LS protocol that it does not require multicast. [RRR] How does one to make discovery? Are you suggesting pre-provisioning? Or, do you like to use DNS stuff-like things where the list of LSs or GWs to be provided? I can imagine scenarios where the size of the ITAD on the network was larger than the space on the network where multicast would route. [RRR] Yes, you are right especially in the case of intra-ITAD. That is why, in the draft (draft-roy-sipproxy-ls-gw-discovery-00.txt), alternative schemes to multicasting for discovery have been proposed. We do not need either a heavy-weight discovery mechanism or a very elaborate scheme for multicasting for the intra-ITAD. [RRR] More discussion along this will be posted soon. Cullen _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Oct 19 22:20:49 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13150 for ; Fri, 19 Oct 2001 22:20:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 97F5F4437E; Fri, 19 Oct 2001 21:15:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 3D00E4437A for ; Fri, 19 Oct 2001 21:14:31 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f9K2KE313765; Fri, 19 Oct 2001 22:20:15 -0400 (EDT) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id WAA02417; Fri, 19 Oct 2001 22:18:55 -0400 (EDT) Received: by NJB140BH2 with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Oct 2001 22:20:13 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: Cullen Jennings , iptel@lists.bell-labs.com Subject: RE: [IPTEL] How many protocols do I need to implement MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 19 Oct 2001 22:20:12 -0400 Cullen: My comments are provided below [RRR]. Radhika -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Friday, October 19, 2001 2:39 PM The LS is going to need TRIP to do the ITRIP and ETRIP type stuff. I am hopeful that I can just tweak this code a bit and not add yet another protocol to get information from the GW. [RRR] Intra-ITAD communications have different requirements (e.g., resolution of destination addresses only - not route propagation etc.) E.164, email IDs, URL IDs; Telephony GWs, SIP-H.323 GWs). So, TRIP is not directly applicable. All we need to do that LSs get all necessary information including TRIP that has been optimized for the telephony routing for inter-ITAD communications. We can make it like-TRIP using the same message formats, but it will be a simple one (not the heavy-weight inter-ITAD TRIP) whether we name it ITRIP or ETRIP is a different matter. If we add a completely different protocol, with a different way of representing attributes, I feel that it will significantly up the issues of 1) defining correct mapping between this protocol and I/E TRIP. 2) up development and particularly test. Similarly, the GW will may need to act like a LS and do ITRIP for cases where there is no LS in the network. [RRR] I would not say that we need a completely different protocol. For example, the draft (draft-roy-iptel-itrp-00.txt) is almost like TRIP (later on, I have proposed that we can use the exact message format of TRIP with some modifications). So, we do not need a new protocol per se. If SLP is clearly better and provides some other things - great but if it just an alternative to TRIP, well I am worried I will now have to do both instead of just one. [RRR] SLP is a new protocol and multicasting is the basis where many services are discovered/advertised (not just GW services). It is a very heavy-weight discovery protocol where many services are advertised or discovered. Cullen _______________________________________________ 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 Oct 19 22:33:49 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14625 for ; Fri, 19 Oct 2001 22:33:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0AF1F4434F; Fri, 19 Oct 2001 21:28:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 71BE94433E for ; Fri, 19 Oct 2001 21:27:53 -0400 (EDT) Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f9K2Xd320819; Fri, 19 Oct 2001 22:33:39 -0400 (EDT) Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id WAA10211; Fri, 19 Oct 2001 22:33:53 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Oct 2001 22:33:34 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: Tom_Gray@Mitel.COM, "Anderson, Darby" Cc: "'Cullen Jennings'" , iptel@lists.bell-labs.com Subject: RE: [IPTEL] GW knowing the cost of calls MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 19 Oct 2001 22:33:33 -0400 Tom: My comments are provided below [RRR]. Radhika From: Tom_Gray@Mitel.COM [mailto:Tom_Gray@Mitel.COM] Sent: Friday, October 19, 2001 3:14 PM To: Anderson, Darby From: Tom Gray@MITEL on 10/19/2001 03:13 PM What sort of route selection policies belong in the gateway? Recall that some routes will be more expensive than others in terms of real money. [RRR] I guess that a SIP call will come to a LS and, LSs will select GWs for a given destination address. If multiple GWs are available to serve the same destination, it is the policy of LS that will determine which GW it needs to select. Now the question is: How does a LS select a GW for given destination? It depends on many factors: QOS, cost, and other service criteria. I believe that we may not standardize these selection criteria now. "Anderson, Darby" on 10/19/2001 02:59:15 PM To: "'Cullen Jennings'" , iptel@lists.bell-labs.com cc: (bcc: Tom Gray/Kan/Mitel) Subject: RE: [IPTEL] GW knowing the cost of calls When you say that a G/W doesnt need to know "a" cost of a call, you mean the G/W on the TERMINATION leg of the call, correct? -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Friday, October 19, 2001 12:39 PM To: iptel@lists.bell-labs.com Subject: [IPTEL] GW knowing the cost of calls The GW should not need to know the cost of any given route in Columbia Laundry Tokens or any other currency. It changes too quickly and the GW are a very difficult place to update it. Let's avoid this path. Cullen _______________________________________________ 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 Fri Oct 19 23:23:49 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16802 for ; Fri, 19 Oct 2001 23:23:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 463A94435C; Fri, 19 Oct 2001 22:18:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 083A244338 for ; Fri, 19 Oct 2001 22:17:27 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9K3NSm10799; Fri, 19 Oct 2001 20:23:28 -0700 (PDT) Received: from cj14 (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ABE76676; Fri, 19 Oct 2001 20:23:13 -0700 (PDT) From: "Cullen Jennings" To: "Roy, Radhika R, ALCTA" , Subject: RE: [IPTEL] Requirement relating to multicast Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 19 Oct 2001 20:29:10 -0700 Content-Transfer-Encoding: 7bit I think we could definitely use some more discussions about provisioning of VoIP components. The discovery of PS, GW, LS and so on seems closely related to provisioning issues. I don't really see any reason that a GW discovering a proxy it connects too has much to do with TRIP. (And I do see the irony of this statement along with my other email thread on how many protocols do I need to implement :-) I don't know, am I missing the boat on this one. I guess it comes back to what are the requirements of TRIP. -----Original Message----- From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] Sent: Friday, October 19, 2001 6:55 PM To: Cullen Jennings; iptel@lists.bell-labs.com Subject: RE: [IPTEL] Requirement relating to multicast Cullen: Please see my comments below [RRR]. Radhika From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Friday, October 19, 2001 2:39 PM I think it should be a requirement of the GW to LS protocol that it does not require multicast. [RRR] How does one to make discovery? Are you suggesting pre-provisioning? Or, do you like to use DNS stuff-like things where the list of LSs or GWs to be provided? I can imagine scenarios where the size of the ITAD on the network was larger than the space on the network where multicast would route. [RRR] Yes, you are right especially in the case of intra-ITAD. That is why, in the draft (draft-roy-sipproxy-ls-gw-discovery-00.txt), alternative schemes to multicasting for discovery have been proposed. We do not need either a heavy-weight discovery mechanism or a very elaborate scheme for multicasting for the intra-ITAD. [RRR] More discussion along this will be posted soon. Cullen _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Oct 19 23:34:49 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17563 for ; Fri, 19 Oct 2001 23:34:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 88AD144374; Fri, 19 Oct 2001 22:29:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 46BF344338 for ; Fri, 19 Oct 2001 22:28:51 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9K3YhU23960; Fri, 19 Oct 2001 20:34:43 -0700 (PDT) Received: from cj14 (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ABE76720; Fri, 19 Oct 2001 20:34:38 -0700 (PDT) From: "Cullen Jennings" To: "Roy, Radhika R, ALCTA" , Subject: RE: [IPTEL] How many protocols do I need to implement Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 19 Oct 2001 20:40:34 -0700 Content-Transfer-Encoding: 7bit Few comments inline [CJ] -----Original Message----- From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] Sent: Friday, October 19, 2001 7:20 PM To: Cullen Jennings; iptel@lists.bell-labs.com Subject: RE: [IPTEL] How many protocols do I need to implement Cullen: My comments are provided below [RRR]. Radhika -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Friday, October 19, 2001 2:39 PM The LS is going to need TRIP to do the ITRIP and ETRIP type stuff. I am hopeful that I can just tweak this code a bit and not add yet another protocol to get information from the GW. [RRR] Intra-ITAD communications have different requirements (e.g., resolution of destination addresses only - not route propagation etc.) E.164, email IDs, URL IDs; Telephony GWs, SIP-H.323 GWs). So, TRIP is not directly applicable. All we need to do that LSs get all necessary information including TRIP that has been optimized for the telephony routing for inter-ITAD communications. We can make it like-TRIP using the same message formats, but it will be a simple one (not the heavy-weight inter-ITAD TRIP) whether we name it ITRIP or ETRIP is a different matter. [CJ] I'm not quite understanding what you are getting at here. Intra ITAD routing may need to export routes - I can imagine ATT wanting to send you to a different proxies depending on if the E.164 number you were calling was in the US or the UK. If we add a completely different protocol, with a different way of representing attributes, I feel that it will significantly up the issues of 1) defining correct mapping between this protocol and I/E TRIP. 2) up development and particularly test. Similarly, the GW will may need to act like a LS and do ITRIP for cases where there is no LS in the network. [RRR] I would not say that we need a completely different protocol. For example, the draft (draft-roy-iptel-itrp-00.txt) is almost like TRIP (later on, I have proposed that we can use the exact message format of TRIP with some modifications). So, we do not need a new protocol per se. [CJ] Agree If SLP is clearly better and provides some other things - great but if it just an alternative to TRIP, well I am worried I will now have to do both instead of just one. [RRR] SLP is a new protocol and multicasting is the basis where many services are discovered/advertised (not just GW services). It is a very heavy-weight discovery protocol where many services are advertised or discovered. Cullen _______________________________________________ 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 Oct 20 00:06:52 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19056 for ; Sat, 20 Oct 2001 00:06:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2B9D74433A; Fri, 19 Oct 2001 23:01:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by lists.bell-labs.com (Postfix) with ESMTP id 0694044338 for ; Fri, 19 Oct 2001 23:01:00 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f9K46lC03790 for ; Sat, 20 Oct 2001 00:06:47 -0400 (EDT) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id WAA02417; Fri, 19 Oct 2001 22:18:55 -0400 (EDT) Received: by NJB140BH2 with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Oct 2001 22:20:13 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: Cullen Jennings , iptel@lists.bell-labs.com Subject: RE: [IPTEL] How many protocols do I need to implement MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 19 Oct 2001 22:20:12 -0400 Cullen: My comments are provided below [RRR]. Radhika -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Friday, October 19, 2001 2:39 PM The LS is going to need TRIP to do the ITRIP and ETRIP type stuff. I am hopeful that I can just tweak this code a bit and not add yet another protocol to get information from the GW. [RRR] Intra-ITAD communications have different requirements (e.g., resolution of destination addresses only - not route propagation etc.) E.164, email IDs, URL IDs; Telephony GWs, SIP-H.323 GWs). So, TRIP is not directly applicable. All we need to do that LSs get all necessary information including TRIP that has been optimized for the telephony routing for inter-ITAD communications. We can make it like-TRIP using the same message formats, but it will be a simple one (not the heavy-weight inter-ITAD TRIP) whether we name it ITRIP or ETRIP is a different matter. If we add a completely different protocol, with a different way of representing attributes, I feel that it will significantly up the issues of 1) defining correct mapping between this protocol and I/E TRIP. 2) up development and particularly test. Similarly, the GW will may need to act like a LS and do ITRIP for cases where there is no LS in the network. [RRR] I would not say that we need a completely different protocol. For example, the draft (draft-roy-iptel-itrp-00.txt) is almost like TRIP (later on, I have proposed that we can use the exact message format of TRIP with some modifications). So, we do not need a new protocol per se. If SLP is clearly better and provides some other things - great but if it just an alternative to TRIP, well I am worried I will now have to do both instead of just one. [RRR] SLP is a new protocol and multicasting is the basis where many services are discovered/advertised (not just GW services). It is a very heavy-weight discovery protocol where many services are advertised or discovered. Cullen _______________________________________________ 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 Oct 21 21:31:18 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19207 for ; Sun, 21 Oct 2001 21:31:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4107744339; Sun, 21 Oct 2001 20:25:09 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by lists.bell-labs.com (Postfix) with ESMTP id D2B5244338 for ; Sun, 21 Oct 2001 20:24:43 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f9M1UiC17436; Sun, 21 Oct 2001 21:30:44 -0400 (EDT) Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id VAA17614; Sun, 21 Oct 2001 21:29:25 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Sun, 21 Oct 2001 21:30:43 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: Cullen Jennings , iptel@lists.bell-labs.com Subject: RE: [IPTEL] Requirement relating to multicast MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Sun, 21 Oct 2001 21:30:43 -0400 Cullen: Please see my comments below [RRR]. Radhika -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Friday, October 19, 2001 11:29 PM To: Roy, Radhika R, ALCTA; iptel@lists.bell-labs.com Subject: RE: [IPTEL] Requirement relating to multicast I think we could definitely use some more discussions about provisioning of VoIP components. The discovery of PS, GW, LS and so on seems closely related to provisioning issues. I don't really see any reason that a GW discovering a proxy it connects too has much to do with TRIP. (And I do see the irony of this statement along with my other email thread on how many protocols do I need to implement :-) [RRR] Without discovery, a LS will not know about GWs if they are not pre-provisioned. In TRIP, it has been assumed that LSs among the different domains are pre-provisioned as it is done in the case of BGP. In inter-domain, it may make sense because of inter-carrier cases. In TRIP, there is nothing mentioned how a LS receives the information of the GWs. [RRR] The relationship between the GWs and LSs is the one that belongs to the intra-ITAD (or intra-domain). Now you are making the assumption that this is also can be pre-provisioned. This is your idea and if you want to do this, no one forcing you to do otherwise. It is your "own" implementation decision. But people want to see that there should be a standardize mechanism for communications for the intra-ITAD: GWs <-> LSs and LSs <-> LSs. TRIP does not specify how these communications take place in intra-ITAD situations. Unless LSs get the required information (e.g., E.164 addresses), it will NOT be able work. TRIP does not need Email ids, URL Ids, etc. [RRR] Let us not down play the communications scenarios for the intra-ITAD just by saying that pre-provision mechanisms are good enough. For intra-ITAD, there are different types of GWs: 1. Telephony GWs (e.g., E.164) and 2. SIP-H.323 GWs. The addresses that we need deal with can be E.164, email IDs, URL IDs, etc. (TRIP addresses only E.164). Unlike TRIP, we need address resolution only, not route propagation. [RRR] For GWs <-> LSs and LSs <-> LSs communications, we need: 1. Discovery and 2. Information/Data transfer between GWs <-> LSs and LSs <-> LSs. For discovery, there can be a. multicasting, b. pre-provisioned, c. DNS-like scheme, and d. others. For information/data transfer, we may use the same message sets what has been used in TRIP with modifications, but it needs to meet intra-ITAD requirements. You seem to be pre-occupied with multicasting only without seeing the complete picture. I don't know, am I missing the boat on this one. I guess it comes back to what are the requirements of TRIP. [RRR] I guess that you are missing some points as explained above. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From ricolin2002@yahoo.com.mx Sun Oct 21 23:09:17 2001 Received: from smtp.prodigy.net.mx (dfproxy03.prodigy.net.mx [148.235.168.59] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21829 for ; Sun, 21 Oct 2001 23:09:16 -0400 (EDT) Received: from endasa (dup-148-233-89-140.prodigy.net.mx [148.233.89.140]) by SMTP.Prodigy.Net.mx (Sun Internet Mail Server sims.4.0.2001.07.26.11.50.p9) with SMTP id <0GLL00HDJ7B4MF@SMTP.Prodigy.Net.mx>; Sun, 21 Oct 2001 21:07:59 -0600 (CST) Date: Sun, 21 Oct 2001 21:09:44 -0600 From: Mercedes Flores =?UNKNOWN?Q?Casta=F1eda?= Subject: 10 NOVIEMBRE, SEMINARIO EL CERRADOR DE VENTAS. CUPO LIMITADO. To: iptel-archive@ietf.org Reply-to: ricolin2002@yahoo.com.mx Message-id: <0GLL00HFN7D6MF@SMTP.Prodigy.Net.mx> MIME-version: 1.0 X-Mailer: Mailer Signature Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 8BIT Content-Transfer-Encoding: 8BIT SEMINARIO EL CERRADOR PROFESIONAL DE VENTAS Temario: 1. Los factores claves para lograr un buen control del proceso de ventas. 2. Como incrementar los ingresos de su empresa por medio de un excelente control del cierre de ventas. 3. La importancia de la comunicacion efectiva en el cierre de ventas. 4. Como interesar al cliente en nuestro producto o servicio. 5. Como manejar en forma experta las objeciones del cliente. 6. Los pasos exactos para lograr el cierre de ventas. 7. Como incrementar su porcentaje de cierres de ventas. 8. Profesionalismo en ventas. 9. Los ingredientes claves para triunfar en ventas. 10. Ejercicios practicos en cada uno de los temas expuestos. Los ejercicios estan dirigidos a la aplicacion de los conocimientos aprendidos para lograr resultados de inmediato. Fecha: Sabado 10 de Noviembre del 2001 Lugar: Hotel Bristol, Salon Bristol, Plaza Necaxa No. 17 Rio Panuco esq. Rio Sena, Col. Cuauhtemoc, D.F. Duracion: 8 horas, 50% del tiempo se dedica a la realizacion de ejercicios practicos. Horario: Seminario de las 9:00 A.M. a las 18:30 P.M. Dirigido a: Ejecutivos de ventas, vendedores y propietarios de negocios. Inversion: $1,900.00 por participante (mas I.V.A.) Incluye: Material de apoyo Coffee Breaks y comida. Conferencista Internacional: Lic. Ricardo Colin Morales. CON MAS DE 20 ANOS DE EXPERIENCIA CAPACITANDO A MILES DE VENDEDORES PARA LA INDUSTRIA. RESERVE HOY MISMO TEL:5543 5961 y 5543 5781 CON LA LIC. MERCEDES FLORES CASTANEDA DIRECTORA DE RELACIONES PUBLICAS, CONSULTORIA EMPRESARIAL PD: Conforme a las leyes nacionales como internacionales este e-mail no podrá ser considerado como SPAM si incluye un procedimiento para ser removido de la lista. Si desea ser removido envienos un e-mail a ricolin2002@yahoo.com.mx, indicandonos a que correo le hemos contactado y en el asunto indique "REMOVER DE LA LISTA" From iptel-admin@lists.bell-labs.com Mon Oct 22 09:34:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16386 for ; Mon, 22 Oct 2001 09:34:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 509B24433C; Mon, 22 Oct 2001 08:28:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by lists.bell-labs.com (Postfix) with ESMTP id 317A644339 for ; Mon, 22 Oct 2001 08:27:18 -0400 (EDT) Received: from gab200r1.ems.att.com ([135.37.94.32]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f9MDXLY29713; Mon, 22 Oct 2001 09:33:21 -0400 (EDT) Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id JAA00272; Mon, 22 Oct 2001 09:33:39 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Oct 2001 09:33:19 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: Cullen Jennings , iptel@lists.bell-labs.com Subject: RE: [IPTEL] How many protocols do I need to implement MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 22 Oct 2001 09:33:17 -0400 Cullen: Please see inline [RRR2]. Thanks for agreeing on the main point. Radhika -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Friday, October 19, 2001 11:41 PM To: Roy, Radhika R, ALCTA; iptel@lists.bell-labs.com Subject: RE: [IPTEL] How many protocols do I need to implement Few comments inline [CJ] -----Original Message----- From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] Sent: Friday, October 19, 2001 7:20 PM To: Cullen Jennings; iptel@lists.bell-labs.com Subject: RE: [IPTEL] How many protocols do I need to implement Cullen: My comments are provided below [RRR]. Radhika -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Friday, October 19, 2001 2:39 PM The LS is going to need TRIP to do the ITRIP and ETRIP type stuff. I am hopeful that I can just tweak this code a bit and not add yet another protocol to get information from the GW. [RRR] Intra-ITAD communications have different requirements (e.g., resolution of destination addresses only - not route propagation etc.) E.164, email IDs, URL IDs; Telephony GWs, SIP-H.323 GWs). So, TRIP is not directly applicable. All we need to do that LSs get all necessary information including TRIP that has been optimized for the telephony routing for inter-ITAD communications. We can make it like-TRIP using the same message formats, but it will be a simple one (not the heavy-weight inter-ITAD TRIP) whether we name it ITRIP or ETRIP is a different matter. [CJ] I'm not quite understanding what you are getting at here. Intra ITAD routing may need to export routes - I can imagine ATT wanting to send you to a different proxies depending on if the E.164 number you were calling was in the US or the UK. [RRR2] In intra-ITAD, it is not really the case. Let me explain. If a SIP call comes to a LS, the LS needs to select a GW for a given destination address. The destination address can be E.164, Email Id, URL Id, or others. Then the SIP call will be directed ot that GW. If we add a completely different protocol, with a different way of representing attributes, I feel that it will significantly up the issues of 1) defining correct mapping between this protocol and I/E TRIP. 2) up development and particularly test. Similarly, the GW will may need to act like a LS and do ITRIP for cases where there is no LS in the network. [RRR] I would not say that we need a completely different protocol. For example, the draft (draft-roy-iptel-itrp-00.txt) is almost like TRIP (later on, I have proposed that we can use the exact message format of TRIP with some modifications). So, we do not need a new protocol per se. [CJ] Agree [RRR2] Great! Let us work to achieve this goal. If SLP is clearly better and provides some other things - great but if it just an alternative to TRIP, well I am worried I will now have to do both instead of just one. [RRR] SLP is a new protocol and multicasting is the basis where many services are discovered/advertised (not just GW services). It is a very heavy-weight discovery protocol where many services are advertised or discovered. Cullen _______________________________________________ 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 Mon Oct 22 12:23:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21901 for ; Mon, 22 Oct 2001 12:23:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F3EE644339; Mon, 22 Oct 2001 11:17:01 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from public.bta.net.cn (public.bta.net.cn [202.96.0.97]) by lists.bell-labs.com (Postfix) with SMTP id 9022D44338 for ; Mon, 22 Oct 2001 11:16:04 -0400 (EDT) Received: from gaolan([61.135.93.8]) by public.bta.net.cn(JetMail 2.5.3.0) with SMTP id jm63bd48b2b; Mon, 22 Oct 2001 16:21:53 -0000 Message-ID: <000a01c15b14$f6e8a5c0$085d873d@gaolan> From: "gao lan" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C15B58.02EB28A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [IPTEL] no subscription 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 23 Oct 2001 00:16:50 +0800 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C15B58.02EB28A0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 bm8gc3Vic2NyaXB0aW9uDQpsZ2FvQHB1YmxpYy5idGEubmV0LmNuDQo= ------=_NextPart_000_0007_01C15B58.02EB28A0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yNjE0LjM1MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5ubyBzdWJzY3JpcHRpb248 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48QSANCmhyZWY9Im1haWx0bzpsZ2FvQHB1 YmxpYy5idGEubmV0LmNuIj5sZ2FvQHB1YmxpYy5idGEubmV0LmNuPC9BPjwvRk9OVD48L0RJVj48 L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0007_01C15B58.02EB28A0-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Oct 22 13:51:14 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25122 for ; Mon, 22 Oct 2001 13:51:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 67A1C44339; Mon, 22 Oct 2001 12:45:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from integraonline.com (web-2-bvtn.integraonline.com [206.163.82.91]) by lists.bell-labs.com (Postfix) with SMTP id D176D44338 for ; Mon, 22 Oct 2001 12:44:33 -0400 (EDT) Received: (qmail 3214 invoked from network); 22 Oct 2001 17:50:46 -0000 Received: from fw-1-bvtn.integratelecom.com (HELO beaexch2.ads.integratelecom.com) ([206.163.82.5]) (envelope-sender ) by web-2-bvtn.integraonline.com (qmail-ldap-1.03) with SMTP for ; 22 Oct 2001 17:50:46 -0000 Received: by beaexch2.ads.integratelecom.com with Internet Mail Service (5.5.2650.21) id ; Mon, 22 Oct 2001 10:50:41 -0700 Message-ID: From: "Anderson, Darby" To: "'Roy, Radhika R, ALCTA'" , Tom_Gray@Mitel.COM, "Anderson, Darby" Cc: "'Cullen Jennings'" , iptel@lists.bell-labs.com Subject: RE: [IPTEL] GW knowing the cost of calls MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 22 Oct 2001 10:50:40 -0700 Sorry for the delay in answering the Question, Im sure this will only further confuse everyone... :/ Maybe Im showing my Old-Iron-Switch/TDM'ism's here... But In my opinion I beleive that the GW should pass the termination #, and the ANI (and Bearer Cap. along with any other parameters from the SS7 cloud)from the G/W to the softswitch, and let the softswitch make any and all routing decisions... am I wrong in my thinking? -----Original Message----- From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] Sent: Friday, October 19, 2001 8:34 PM To: Tom_Gray@Mitel.COM; Anderson, Darby Cc: 'Cullen Jennings'; iptel@lists.bell-labs.com Subject: RE: [IPTEL] GW knowing the cost of calls Tom: My comments are provided below [RRR]. Radhika From: Tom_Gray@Mitel.COM [mailto:Tom_Gray@Mitel.COM] Sent: Friday, October 19, 2001 3:14 PM To: Anderson, Darby From: Tom Gray@MITEL on 10/19/2001 03:13 PM What sort of route selection policies belong in the gateway? Recall that some routes will be more expensive than others in terms of real money. [RRR] I guess that a SIP call will come to a LS and, LSs will select GWs for a given destination address. If multiple GWs are available to serve the same destination, it is the policy of LS that will determine which GW it needs to select. Now the question is: How does a LS select a GW for given destination? It depends on many factors: QOS, cost, and other service criteria. I believe that we may not standardize these selection criteria now. "Anderson, Darby" on 10/19/2001 02:59:15 PM To: "'Cullen Jennings'" , iptel@lists.bell-labs.com cc: (bcc: Tom Gray/Kan/Mitel) Subject: RE: [IPTEL] GW knowing the cost of calls When you say that a G/W doesnt need to know "a" cost of a call, you mean the G/W on the TERMINATION leg of the call, correct? -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Friday, October 19, 2001 12:39 PM To: iptel@lists.bell-labs.com Subject: [IPTEL] GW knowing the cost of calls The GW should not need to know the cost of any given route in Columbia Laundry Tokens or any other currency. It changes too quickly and the GW are a very difficult place to update it. Let's avoid this path. Cullen _______________________________________________ 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 Mon Oct 22 14:47:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26898 for ; Mon, 22 Oct 2001 14:47:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 257DB44344; Mon, 22 Oct 2001 13:41:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by lists.bell-labs.com (Postfix) with ESMTP id 04E3B44338 for ; Mon, 22 Oct 2001 13:40:01 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f9MIhta06295; Mon, 22 Oct 2001 11:43:59 -0700 (PDT) Received: from fluffyw2k (dhcp-128-107-142-47.cisco.com [128.107.142.47]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ABE93317; Mon, 22 Oct 2001 11:45:59 -0700 (PDT) From: "Cullen Jennings" To: "Anderson, Darby" , "'Roy, Radhika R, ALCTA'" , Cc: Subject: RE: [IPTEL] GW knowing the cost of calls Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 22 Oct 2001 11:45:12 -0700 Content-Transfer-Encoding: 7bit Yes, I think lots of deployments will do it that way. Some may not but it definitely needs to be a possible way to do it. I think SIP and H.323 more or less both support this. > -----Original Message----- > From: iptel-admin@lists.bell-labs.com > [mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Anderson, Darby > Sent: Monday, October 22, 2001 10:51 AM > To: 'Roy, Radhika R, ALCTA'; Tom_Gray@Mitel.COM; Anderson, Darby > Cc: 'Cullen Jennings'; iptel@lists.bell-labs.com > Subject: RE: [IPTEL] GW knowing the cost of calls > > > Sorry for the delay in answering the Question, Im sure this will only > further confuse everyone... :/ > > Maybe Im showing my Old-Iron-Switch/TDM'ism's here... But In my > opinion I > beleive that the GW should pass the termination #, and the ANI (and Bearer > Cap. along with any other parameters from the SS7 cloud)from the > G/W to the > softswitch, and let the softswitch make any and all routing decisions... > > am I wrong in my thinking? > > -----Original Message----- > From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] > Sent: Friday, October 19, 2001 8:34 PM > To: Tom_Gray@Mitel.COM; Anderson, Darby > Cc: 'Cullen Jennings'; iptel@lists.bell-labs.com > Subject: RE: [IPTEL] GW knowing the cost of calls > > > Tom: > > My comments are provided below [RRR]. > > Radhika > > From: Tom_Gray@Mitel.COM [mailto:Tom_Gray@Mitel.COM] > Sent: Friday, October 19, 2001 3:14 PM > To: Anderson, Darby > > From: Tom Gray@MITEL on 10/19/2001 03:13 PM > > What sort of route selection policies belong in the gateway? > > Recall that some routes will be more expensive than others in > terms of real > money. > > [RRR] I guess that a SIP call will come to a LS and, LSs will > select GWs for > a given destination address. If multiple GWs are available to > serve the same > destination, it is the policy of LS that will determine which GW > it needs to > select. Now the question is: How does a LS select a GW for given > destination? It depends on many factors: QOS, cost, and other service > criteria. I believe that we may not standardize these selection criteria > now. > > > > "Anderson, Darby" on > 10/19/2001 02:59:15 > PM > > To: "'Cullen Jennings'" , iptel@lists.bell-labs.com > cc: (bcc: Tom Gray/Kan/Mitel) > > Subject: RE: [IPTEL] GW knowing the cost of calls > > > > When you say that a G/W doesnt need to know "a" cost of a call, > you mean the > G/W on the TERMINATION leg of the call, correct? > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Friday, October 19, 2001 12:39 PM > To: iptel@lists.bell-labs.com > Subject: [IPTEL] GW knowing the cost of calls > > > > The GW should not need to know the cost of any given route in Columbia > Laundry Tokens or any other currency. It changes too quickly and > the GW are > a very difficult place to update it. Let's avoid this path. > > Cullen > > > > > _______________________________________________ > 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 > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From endasa2001@yahoo.com.mx Fri Oct 26 20:12:55 2001 Received: from correo.cablevision.net.mx (na-148-243-251-143.na.avantel.net.mx [148.243.251.143] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20830 for ; Fri, 26 Oct 2001 20:12:54 -0400 (EDT) Message-Id: <200110270012.UAA20830@ietf.org> Received: from cybercityvalle ([10.5.1.10]) by correo.cablevision.net.mx (Netscape Messaging Server 4.15) with SMTP id GLTSD600.BMI for ; Fri, 26 Oct 2001 13:22:18 -0500 From: "Enrique O. Dávila Santiago" To: iptel-archive@ietf.org Subject: VETE AL PARAISO, CANCÚN PUERTO AVENTURAS, PROMOCIÓN X-Mailer: Mailer Signature Reply-To: endasa2001@yahoo.com.mx Date: Fri, 26 Oct 2001 13:21:33 -0600 Mime-Version: 1.0 Content-Type: text/html; charset=us-ascii RENTO TIEMPO COMPARTIDO PARA 6 PERSONAS, DEL 29 DE DICIEMBRE DEL 2001 AL 5 DE ENERO DEL 2002, DESARROLLO CINCO ESTRELLAS. POR ENCONTRARSE EN UN TERCER PISO TIENES HERMOSAS VISTAS A LA MARINA Y A LAS PLAYAS PRIVADAS, VARIAS ALBERCAS, EL DESARROLLO CUENTA CON DISCOTECA, EXCELENTES RESTAURANTES, ZONA ARQUEÓLOGICA, JETS SKY, BANANAS, DOS CANCHAS DE TENIS, EVENTOS VARIOS EN PLAYAS PARA LOS HUÉSPEDES, LA SUITE CUENTA CON DOS RECAMARAS, COCINETA EQUIPADA, DOS BAÑOS, TELEVISORES, EN FIN TODO LO NECESARIO PARA QUE PASES UNA SEMANA INOLVIDABLE. ¿EL COSTO? UNA GANGA $ 15,000.00 M.N. ( POR TODA LA SEMANA.) INFORMES CON EL SR. ENRIQUE DÁVILA SANTIAGO A LOS TELEFONOS 044-5454-3352, 5606-5035 O AL CORREO ELECTRONICO endasa@prodigy.net.mx o endasa2001@yahoo.com.mx From ricolin2002@terra.com.mx Tue Oct 30 13:48:20 2001 Received: from smtp.prodigy.net.mx (dfproxy01.prodigy.net.mx [148.235.168.56] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11097 for ; Tue, 30 Oct 2001 13:48:19 -0500 (EST) Received: from endasa (dup-148-233-90-223.prodigy.net.mx [148.233.90.223]) by smtp.prodigy.net.mx (Sun Internet Mail Server sims.4.0.2001.07.26.11.50.p9) with SMTP id <0GM100K5R80MUR@smtp.prodigy.net.mx>; Tue, 30 Oct 2001 12:45:24 -0600 (CST) Date: Tue, 30 Oct 2001 12:46:00 -0600 From: "Lic. Mercedes Flores =?UNKNOWN?Q?Casta=F1eda?=" Subject: 10 NOVIEMBRE, SEMINARIO EL CERRADOR DE VENTAS. CUPO LIMITADO. To: iptel-archive@ietf.org Reply-to: ricolin2002@terra.com.mx Message-id: <0GM100K9383KUR@smtp.prodigy.net.mx> MIME-version: 1.0 X-Mailer: Mailer Signature Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 8BIT Content-Transfer-Encoding: 8BIT SEMINARIO EL CERRADOR PROFESIONAL DE VENTAS Temario: 1. Los factores claves para lograr un buen control del proceso de ventas. 2. Como incrementar los ingresos de su empresa por medio de un excelente control del cierre de ventas. 3. La importancia de la comunicacion efectiva en el cierre de ventas. 4. Como interesar al cliente en nuestro producto o servicio. 5. Como manejar en forma experta las objeciones del cliente. 6. Los pasos exactos para lograr el cierre de ventas. 7. Como incrementar su porcentaje de cierres de ventas. 8. Profesionalismo en ventas. 9. Los ingredientes claves para triunfar en ventas. 10. Ejercicios practicos en cada uno de los temas expuestos. Los ejercicios estan dirigidos a la aplicacion de los conocimientos aprendidos para lograr resultados de inmediato. Fecha: Sabado 10 de Noviembre del 2001 Lugar: Hotel Bristol, Salon Bristol, Plaza Necaxa No. 17 Rio Panuco esq. Rio Sena, Col. Cuauhtemoc, D.F. Duracion: 8 horas, 50% del tiempo se dedica a la realizacion de ejercicios practicos. Horario: Seminario de las 9:00 A.M. a las 18:30 P.M. Dirigido a: Ejecutivos de ventas, vendedores y propietarios de negocios. Inversion: $1,900.00 por participante (mas I.V.A.) Incluye: Material de apoyo Coffee Breaks y comida. Conferencista Internacional: Lic. Ricardo Colin Morales. CON MAS DE 20 ANOS DE EXPERIENCIA CAPACITANDO A MILES DE VENDEDORES PARA LA INDUSTRIA. RESERVE HOY MISMO TEL:5543 5961 y 5543 5781 CON LA LIC. MERCEDES FLORES CASTANEDA DIRECTORA DE RELACIONES PUBLICAS, CONSULTORIA EMPRESARIAL PD: Conforme a las leyes nacionales como internacionales este e-mail no podrá ser considerado como SPAM si incluye un procedimiento para ser removido de la lista. Si desea ser removido envienos un e-mail a ricolin2002@terra.com.mx, indicandonos a que correo le hemos contactado y en el asunto indique "REMOVER DE LA LISTA" From iptel-admin@lists.bell-labs.com Wed Oct 31 22:39:29 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09781 for ; Wed, 31 Oct 2001 22:39:29 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3161D44337; Wed, 31 Oct 2001 21:32:03 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from flashmail.com (flash2.flashmail.com [207.173.216.241]) by lists.bell-labs.com (Postfix) with SMTP id D812F44336 for ; Wed, 31 Oct 2001 21:31:46 -0500 (EST) Received: (qmail 26806 invoked from network); 1 Nov 2001 03:40:39 -0000 Received: from unknown (HELO flashmail.com) (207.173.216.240) by flash2.flashmail.com with SMTP; 1 Nov 2001 03:40:39 -0000 From: "Nitin Kumar" Reply-To: cipher_nitin@flashmail.com To: iptel@lists.bell-labs.com Message-id: <3be0c45c.223.0@flashmail.com> X-User-Info: 203.190.136.98 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: [IPTEL] a doubt on TRIP 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.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 31 Oct 2001 19:41:16 -0800 Content-Transfer-Encoding: 7bit Hello, My name is Nitin Mahajan and the reason I am writting to you is because I had just read the draft on TRIP i.e draft-ietf-iptel-trip-09.txt. I had some doubts which if you could please clarify (jonathan rosenberg has referred me to you). For decision process architecture the draft says of rules to be followed for tie breaks. Now, I could see in Sec 10.2.2.1 the 3 rules to be used for tie break (for internal as well as external ) but, the draft mentions the 2 rules to be used for tie breaks (for external peers) again in Sec 10.3.1.1. Though the rules in the later section boil down to be same, but why are they given again , am I missing something ? Also, isn't the 2nd point in the later Section 10.3.1.1 mentions the use of TRIP Identifier for tie break , shouldn't it be ITAD number ? As otherwise don't we leave an another chance of tie ? Please correct me if I am going wrong somwhere ( this is my first time reading such draft). Thanks in Advance, Nitin ______________________________________________________ Get Your FREE FlashMail Address now at http://www.flashmail.com It's Free, Easy, & Fun !!! _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel