From richard@shockey.us Tue Mar 3 07:15:24 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA49A28C285 for ; Tue, 3 Mar 2009 07:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.249 X-Spam-Level: X-Spam-Status: No, score=-0.249 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XId-w0jx3m1q for ; Tue, 3 Mar 2009 07:15:23 -0800 (PST) Received: from outbound-mail-23.bluehost.com (outbound-mail-23.bluehost.com [69.89.21.18]) by core3.amsl.com (Postfix) with SMTP id 9F17528C2AF for ; Tue, 3 Mar 2009 07:15:23 -0800 (PST) Received: (qmail 3306 invoked by uid 0); 3 Mar 2009 15:15:11 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy2.bluehost.com with SMTP; 3 Mar 2009 15:15:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=CXkYZGqb9oyuwrvVE8yqxU/7OyU+OCHI/M7tR6P6gz759/kfIXpYHkmRw8gdKA4Y0YjVWcQRGwQguf8Nd4PTT55g79j+/2VsBj7SyWGmA2kNJpqeVdbbjVZ0TZSi6maP; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1LeWLW-0002Bg-IW for drinks@ietf.org; Tue, 03 Mar 2009 08:15:50 -0700 From: "Richard Shockey" To: "'IETF DRINKS WG'" Date: Tue, 3 Mar 2009 10:15:28 -0500 Message-ID: <011d01c99c12$e45240f0$acf6c2d0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmcEuKnVhb8xPz0R5S5GRJvQPiI8g== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Subject: [drinks] I'd like to finalize any agenda items other than the use case.. X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 15:15:24 -0000 Do we have anything more? Richard Shockey PSTN Mobile: +1 703.593.2683 From alexander.mayrhofer@nic.at Tue Mar 3 07:40:30 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF9353A6784 for ; Tue, 3 Mar 2009 07:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.13 X-Spam-Level: X-Spam-Status: No, score=-8.13 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oekY3zoCfHql for ; Tue, 3 Mar 2009 07:40:30 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [192.174.68.200]) by core3.amsl.com (Postfix) with ESMTP id 8A8723A67BD for ; Tue, 3 Mar 2009 07:40:29 -0800 (PST) Received: from localhost [127.0.0.1] by mail.sbg.nic.at with XWall v3.44 ; Tue, 3 Mar 2009 16:40:54 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 3 Mar 2009 16:40:53 +0100 Message-ID: <8BC845943058D844ABFC73D2220D4665080713D9@nics-mail.sbg.nic.at> In-Reply-To: <011d01c99c12$e45240f0$acf6c2d0$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [drinks] I'd like to finalize any agenda items other than the usecase.. Thread-Index: AcmcEuKnVhb8xPz0R5S5GRJvQPiI8gAA2UMw References: <011d01c99c12$e45240f0$acf6c2d0$@us> From: "Alexander Mayrhofer" To: "Richard Shockey" , "IETF DRINKS WG" X-XWALL-BCKS: auto Subject: Re: [drinks] I'd like to finalize any agenda items other than the usecase.. X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 15:40:31 -0000 =20 >>=20 > Do we have anything more? *if* i get a draft done by tomorrow (probably just a placeholder in the first place), we might have a draft about "potential SED elements". I'll try to get it done before the deadline. Alex From richard@shockey.us Tue Mar 3 08:47:12 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 841CE3A690E for ; Tue, 3 Mar 2009 08:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5lFAN5ybh77 for ; Tue, 3 Mar 2009 08:47:11 -0800 (PST) Received: from outbound-mail-145.bluehost.com (outbound-mail-145.bluehost.com [67.222.38.35]) by core3.amsl.com (Postfix) with SMTP id 9F0173A679C for ; Tue, 3 Mar 2009 08:47:11 -0800 (PST) Received: (qmail 3662 invoked by uid 0); 3 Mar 2009 16:44:51 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy5.bluehost.com with SMTP; 3 Mar 2009 16:44:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=jup8L3Zs+32xf/FMtOkQv/9sKakpz+d0vmcfHdvuw/w6rLXvck2m3DMcVMdVEspXSTDSbO3EQoAbBcuviurL3K/EFmJSu6qKBPxyaqQ1Xcp4erY4UK3gPEbDv+AwlhcK; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1LeXmL-000082-P6 for drinks@ietf.org; Tue, 03 Mar 2009 09:47:38 -0700 From: "Richard Shockey" To: "'IETF DRINKS WG'" Date: Tue, 3 Mar 2009 11:47:16 -0500 Message-ID: <015b01c99c1f$b6b6c3c0$24244b40$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmcH7XLanzWxoy1Tbmueg91/pynDA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Subject: [drinks] PRELIMINARY AGENDA X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 16:47:12 -0000 IETF 74 DRINKS Agenda - PRELIMINARY Data for Reachability of Inter/tra-NetworK SIP (drinks) TUESDAY, March 24, 2009 0800-1800 IETF Registration - Yosemite Foyer 0800-0900 Continental Breakfast - Yosemite Foyer/East Lounge 0900-1130 Morning Session I Continental 1&2 RAI drinks Data for Reachability of Inter/tra-NetworK SIP WG Chair(s): Richard Shockey Alexander Mayrhofer WG Secretary RAI Director(s): Jon Peterson jon.peterson@neustar.biz Cullen Jennings fluffy@cisco.com RAI Area Advisor: Jon Peterson jon.peterson@neustar.biz Agenda Bashing. 1. Title : DRINKS Use cases and Protocol Requirements Author(s) : S. Channabasappa Filename : draft-channabasappa-drinks-usecases-requirements-02.txt Pages : 22 Date : 2009-02-03 This document captures the use cases and associated requirements for interfaces to provision session establishment data into SIP Service Provider components that aid with session routing. Specifically, the current version of this document focuses on the provisioning of one such element, termed the registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-channabasappa-drinks-usecases-requ irements-02.txt ? "potential SED elements" ?. Issues involving how provisioning Private Peering data fits into the DRINKS model. General Discussion ... Richard Shockey PSTN Mobile: +1 703.593.2683 From alexander.mayrhofer@nic.at Wed Mar 4 08:17:33 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 410E33A6B3C for ; Wed, 4 Mar 2009 08:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.997 X-Spam-Level: X-Spam-Status: No, score=-8.997 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMAyowEbuvwi for ; Wed, 4 Mar 2009 08:17:31 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [192.174.68.200]) by core3.amsl.com (Postfix) with ESMTP id 414283A691A for ; Wed, 4 Mar 2009 08:17:30 -0800 (PST) Received: from localhost [127.0.0.1] by mail.sbg.nic.at with XWall v3.44 ; Wed, 4 Mar 2009 17:17:57 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 4 Mar 2009 17:17:57 +0100 Message-ID: <8BC845943058D844ABFC73D2220D4665080714DA@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fw: I-D Action:draft-mayrhofer-drinks-sed-elements-00.txt Thread-Index: Acmc5MehhLSSa9Z1Rk2cj6lmvro83w== From: "Alexander Mayrhofer" To: "IETF DRINKS WG" X-XWALL-BCKS: auto Subject: [drinks] Fw: I-D Action:draft-mayrhofer-drinks-sed-elements-00.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 16:17:34 -0000 FYI - i've created a list of potential data elements for SED - feedback welcome.=20 Alex --------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Potential Elements of Session Establishment Data Author(s) : A. Mayrhofer Filename : draft-mayrhofer-drinks-sed-elements-00.txt Pages : 6 Date : 2009-03-04 This document provides a list of potential Session Establishment Data Elements in the Scope of SPEERMINT/DRINKS work. The list is provided to seek input from the community, and with the intent to aid in the definition of DRINKS requirements/protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mayrhofer-drinks-sed-elements- 00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From richard@shockey.us Tue Mar 10 06:15:10 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E9DC3A6967 for ; Tue, 10 Mar 2009 06:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[AWL=-0.473, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnGdzQAMQzVb for ; Tue, 10 Mar 2009 06:15:09 -0700 (PDT) Received: from outbound-mail-301.bluehost.com (outbound-mail-301.bluehost.com [67.222.53.8]) by core3.amsl.com (Postfix) with SMTP id 5262D28C10E for ; Tue, 10 Mar 2009 06:15:09 -0700 (PDT) Received: (qmail 13937 invoked by uid 0); 10 Mar 2009 13:10:36 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy6.bluehost.com with SMTP; 10 Mar 2009 13:10:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=W6rTCjLs4vSBOv1qFoqcxk8ScmxmIf77NLxFf89++T1UnK8kCnCreAzJn/bHbbAeDS7TuUJKeODizR3yXSjYCeIt+cMZ0O7CPV6HTZIVGYbBXP26jQtJPiwLXHGJj4kt; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Lh1o7-0007oU-6w for drinks@ietf.org; Tue, 10 Mar 2009 07:15:43 -0600 From: "Richard Shockey" To: "'IETF DRINKS WG'" Date: Tue, 10 Mar 2009 09:15:21 -0400 Message-ID: <00c001c9a182$4545ea00$cfd1be00$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmhgkPsJzfjDHdbSOa3GI7u+MKlvg== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Subject: [drinks] FINAL AGENDA ??? X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 13:15:10 -0000 I'm assuming at this time we have nothing more to discuss unless we want to have another very long winded discussion of LUF vs LRF? Who will be presenting the use cases document? IETF 74 DRINKS Agenda - FINAL ??? Data for Reachability of Inter/tra-NetworK SIP (drinks) TUESDAY, March 24, 2009 0800-1800 IETF Registration - Yosemite Foyer 0800-0900 Continental Breakfast - Yosemite Foyer/East Lounge 0900-1130 Morning Session I Continental 1&2 RAI drinks Data for Reachability of Inter/tra-NetworK SIP WG Chair(s): Richard Shockey Alexander Mayrhofer WG Secretary RAI Director(s): Jon Peterson jon.peterson@neustar.biz Cullen Jennings fluffy@cisco.com RAI Area Advisor: Jon Peterson jon.peterson@neustar.biz Agenda Bashing. 1. Title : DRINKS Use cases and Protocol Requirements Author(s) : S. Channabasappa Filename : draft-channabasappa-drinks-usecases-requirements-02.txt Pages : 22 Date : 2009-02-03 This document captures the use cases and associated requirements for interfaces to provision session establishment data into SIP Service Provider components that aid with session routing. Specifically, the current version of this document focuses on the provisioning of one such element, termed the registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-channabasappa-drinks-usecases-requ irements-02.txt 2. Title : Potential Elements of Session Establishment Data Author(s) : A. Mayrhofer Filename : draft-mayrhofer-drinks-sed-elements-00.txt Pages : 6 Date : 2009-03-04 This document provides a list of potential Session Establishment Data Elements in the Scope of SPEERMINT/DRINKS work. The list is provided to seek input from the community, and with the intent to aid in the definition of DRINKS requirements/protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mayrhofer-drinks-sed-elements- 00.txt 3. Issues involving how provisioning Private Peering data fits into the DRINKS model. General Discussion ... Richard Shockey PSTN Mobile: +1 703.593.2683 From sumanth@cablelabs.com Tue Mar 17 15:08:35 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EDA23A69FE for ; Tue, 17 Mar 2009 15:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.587 X-Spam-Level: X-Spam-Status: No, score=0.587 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9PKJ+W8cw+o for ; Tue, 17 Mar 2009 15:08:34 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 036DD3A6873 for ; Tue, 17 Mar 2009 15:08:33 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n2HM9GeK025144; Tue, 17 Mar 2009 16:09:16 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 17 Mar 2009 16:09:16 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Mar 2009 16:09:16 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C601A1ADA6@srvxchg3.cablelabs.com> In-Reply-To: <49A7063C.6080503@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [drinks] Some comments on the use-cases draft Thread-Index: AcmYV0H85mJ+/Va9SVKA4skQRneoEAO8ga2w References: <49A7063C.6080503@nic.at> From: "Sumanth Channabasappa" To: "Otmar Lendl" , "IETF DRINKS WG" X-Approved: ondar Subject: Re: [drinks] Some comments on the use-cases draft X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2009 22:08:35 -0000 Otmar,=20 Thanks for your comments. I guess we - as in the design team - were expecting more feedback prior to responding, or we got busy. Anyway, I will start with some quick responses and let the design team pitch in with additional thoughts.=20 ---- * This is a telco design. Basic bell-head thinking with only some marginal sprinkling of Internet ideas. This is a document which describes how one might carry over the telco provisioning, interconnection and call routing approaches to the VoIP world. All fine and good, but to be provocative: why is this an IETF WG document and not an ITU-T, OASIS or 3GPP paper? The role model, the actors and a most use-cases are almost straight from the PSTN playbook. [S] Can you provide specific use cases that you would have rather liked to see (in addition to your thoughts later on in the email, which help some)?=20 As a note, I am not questioning your observation! The current use cases are based on perceived industry needs (by the design team). It will be nice to see how we can make it more relevant, if it is not. ---- * This is way too ambitious on one hand. Defining all this in a single protocol and implementing the registry which actually does all these things is a herculean task. Layering, folks. Layering. [S] Ah! Keep in mind that this is a requirements document. We can prioritize and specify protocol phases if the WG feels that this is too much at once! :) ---- Divide the problem into discrete, clearly separated sub-problems (see the speermint LUF/LRF split for a good one) and the complexity can be brought under control. [S] Good suggestion - although I am unsure of the LUF/LRF example :^) ---- * This is way too conservative on the other hand. There is little dynamic routing. There is no integration of enterprise VoIP routing with carrier routing. There no possibility of ad-hoc peering. [S] The use cases are not all encompassing, as you rightly indicate. We should consider things we have not discussed yet, such as your suggestions. ---- > SED Record: A SED Record contains much of the session establishment > data or a 'redirect' to another registry where the session > establishment data can be discovered. SED Records types supported > are NAPTRs, CNAME, DNAME, and NS Records. What about TLS parameters, Source IP addresses of SBEs, Codec constraints, SIP profiles, ... This is far too DNS focussed. [S] I agree. We need to consider parameters specified in Section 3.3, RFC5486. ---- > SED is typically created by the terminating SSP and consumed by the > originating SSP. Careful here: in the case of multi-hop routing, the SED towards the next hop are relevant, and these may have little to do with whatever the terminating SSP has created. See 4.2.2. of the speermint terminology draft. [S] I concur; we need to clarify this point.=20 ---- > For scalability reasons SED is rarely exchanged > directly between the intended parties. Instead, it is exchanged via > intermediate systems - termed Registries within this document. Such > registries receive SED via provisioning transactions from other SSPs, > and then distribute the received data into Local Data Repositories. This is true for anything dealing with TNs. Once these are mapped to something amenable to aggregation, this argument falls completely down. We have a serious mistake in the base assumptions here. If we do proper layering, then the routing information does *not* need these intermediate registries. The registries are only needed for the TN -> Destination-Group mapping. Yes, that's the way it has been done in the PSTN and thus it would be easy to integrate VoIP into the same provisioning processes. That's one of the fundamental design question: do we design an incremental update to the way carriers have been operating, or do we design an addition to the IETF SIP world which enables scalable multihop routing based on TNs? These are two very different goals. [S] Interesting! I will have to think about this some more. I will let the WG pitch in on this! ---- > o Registries are the authoritative source for provisioned session > establishment data (SED) and related information. Eeek. SED includes what the next hop is. In a dynamic network, this can change quickly as SBEs or links fail, congestion makes paths unavailable or some business decisions make a different path more attractive. I cannot fathom that * these real-time routing information is exchanged via the registry, * carriers outsource the business decision part of the call routing algorithm to third parties. [S] In the current paradigm (within the I-D), the registry will need to be updated to reflect changes, which is then propagated to local data repositories. The provisioned data should ideally be resilient to hiccups (e.g., contain multiple routes to account for backups, prioritization). Isn't the ability to dynamically provision data one of the reasons why we want to work on this? Perhaps I am misunderstanding the comment. ---- - S From lendl@nic.at Mon Mar 23 14:14:02 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C62D93A69D1 for ; Mon, 23 Mar 2009 14:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYBFK31H0IlI for ; Mon, 23 Mar 2009 14:14:01 -0700 (PDT) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 305E43A6887 for ; Mon, 23 Mar 2009 14:14:00 -0700 (PDT) Received: from [10.20.30.241] (alix.bofh.priv.at [213.129.239.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTP id 2B9994C44C; Mon, 23 Mar 2009 22:14:48 +0100 (CET) Message-ID: <49C7FBC8.90305@nic.at> Date: Mon, 23 Mar 2009 22:14:48 +0100 From: Otmar Lendl User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Sumanth Channabasappa References: <49A7063C.6080503@nic.at> <9AAEDF491EF7CA48AB587781B8F5D7C601A1ADA6@srvxchg3.cablelabs.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C601A1ADA6@srvxchg3.cablelabs.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF DRINKS WG Subject: Re: [drinks] Some comments on the use-cases draft X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 21:14:02 -0000 Sumanth, Just some quick notes, I hope you have a good session tomorrow. It's unlikely that I can join via Jabber. Sumanth Channabasappa wrote: > Thanks for your comments. I guess we - as in the design team - were > expecting more feedback prior to responding, or we got busy. Let's hope where will be a discussion here. > ---- > * This is a telco design. Basic bell-head thinking with only some > marginal > sprinkling of Internet ideas. This is a document which describes how one > might carry over the telco provisioning, interconnection and call > routing approaches to the VoIP world. > > All fine and good, but to be provocative: why is this an IETF WG > document > and not an ITU-T, OASIS or 3GPP paper? The role model, the actors and a > most use-cases are almost straight from the PSTN playbook. > [S] Can you provide specific use cases that you would have rather liked > to see (in addition to your thoughts later on in the email, which help > some)? Here are some scenarios: * Enterprise PBX with multiple connections to carriers, trying to optimize outgoing calls. * Any form of ad-hoc, not manually pre-configured peering. * e.g.: All PBXs of an industry sector want to peer, and authenticate based on TLS certs by some trade group. More importantly, I have this nagging feeling that most of your use-cases imply that there will be a central registry which will feed the data back into local data repositories. I don't see this as a given for the routing part. > As a note, I am not questioning your observation! The current use cases > are based on perceived industry needs (by the design team). It will be > nice to see how we can make it more relevant, if it is not. Well, given the people on the design team who are either used to utilize such a setup or provide this registry, this is not surprising. > ---- > > * This is way too ambitious on one hand. Defining all this in a single > protocol and implementing the registry which actually does all these > things is a herculean task. > > Layering, folks. Layering. > [S] Ah! Keep in mind that this is a requirements document. We can > prioritize and specify protocol phases if the WG feels that this is too > much at once! :) You're requirements are based on a design decision (all data exchange is via the same protocol and possibly all via a registry). Take that away, e.g. "do the TN -> routing group mapping via a registry, but do the routing peer2peer between connected SSPs", and you get instant layering. And then it isn't "protocol phases", but two completely distinct protocols. > ---- >> SED Record: A SED Record contains much of the session > establishment >> data or a 'redirect' to another registry where the session >> establishment data can be discovered. SED Records types > supported >> are NAPTRs, CNAME, DNAME, and NS Records. > > What about TLS parameters, Source IP addresses of SBEs, Codec > constraints, > SIP profiles, ... > > This is far too DNS focussed. > [S] I agree. We need to consider parameters specified in Section 3.3, > RFC5486. See Alex's draft and also draft-hancock-sip-interconnect-guidelines-00. > ---- > >> o Registries are the authoritative source for provisioned session >> establishment data (SED) and related information. > > Eeek. > > SED includes what the next hop is. In a dynamic network, this can change > quickly as SBEs or links fail, congestion makes paths unavailable or > some > business decisions make a different path more attractive. > > I cannot fathom that > > * these real-time routing information is exchanged via the registry, > > * carriers outsource the business decision part of the call routing > algorithm to third parties. > [S] In the current paradigm (within the I-D), the registry will need to > be updated to reflect changes, which is then propagated to local data > repositories. The provisioned data should ideally be resilient to > hiccups (e.g., contain multiple routes to account for backups, > prioritization). Isn't the ability to dynamically provision data one of > the reasons why we want to work on this? I think we're back to the fundamental outlook towards this problem. One can look at the problem space from the telco point of view, where you have a relatively static network. Each border element is hardcore telco-grade equipment, inherently redundant and likely clustered as well. You don't plan that such a border element is unavailable in toto often. In the Internet world, this is a bit like HTTP and email: You usually don't change the DNS for simple fallback scenarios: you might have a few A (or MX) records, but the real redundancy is provides by load-balancers and heavy duty server machinery. SIP with the NAPTR/SRV lookups uses the same approach: on failure of the primary element, fall back to others. Once you go to the Internet Routing layer, this changes. If a router (or link) fails, the BGP session goes down and another path has to be selected. There is no "hmm, let's try this other MAC address, maybe there is a standby device." You don't do VRRP or any of these cluster-features in the routing space. On failure, you just let the routing protocol select a new path. Instantly. This is a bit like the RAID principle: you don't build a single, super-reliable disk, but combine cheap disks with a bit intelligence and you get good reliability. Now, the question is, what's the better routing model for what we are trying to achieve here? The original SIP design is simple: directly connect to the destination network via the common IP transport network. There is no multi-hop routing problem on the SIP layer. Failures in the transmission layers are covered by the IP routing protocols, so SIP never needed to care. SRV records suffice to loadbalance/fallback within the destination network. All fine and dandy. Except that this is not what happened in the real world. There is no single common IP network for VoIP. There are a bunch of interconnection networks and private peering links in addition to the public Internet. VoIP routing is thus a multihop routing problem. And for a multihop routing problem, the NAPTR/SRV fallback mechanisms are NOT ENOUGH. Example network diagram: A -- B -- C -- D \ / - E -- F A has paths ABCD and AEFD to D. Now assume A is using the ABCD path. INVITES are passed along, but suddenly C fails to be reachable by B. B can try all the other SRV records of C it finds, but it just can't pass on the call. A has to learn of this link failure and route to E instead. Yes, it is possible to do this with a central registry: all players need keep it up to date in real-time with respect to link/SBE/DBE failures. That registry needs to have a complete map and state of all links between all SSPs in order to play the routing oracle. (How C could tell the registry that it just lost power to it's datacenter, and thus can't act as a transit network any more is beyond me.) This is a monopoly position and a single point of failure for the whole Voice Network. Or, alternatively, you go for the BGP model and let B tell A "sorry, I can't reach C and D any more". Directly from border-element to border-element. You might say that such link failures are rare. Maybe they are if you think only of real large carriers and their 5-nines equipment. That's not necessarily all there is to VoIP. There are enough pure-VoIP startups, and (at least here in Austria) a good number of local cable networks are providing IP and VoIP services as well. Corporate PBXs are another example. It's a question of where you put in your redundancy: fortify the nodes or prepare for failed nodes with a really dynamic routing protocol. I just can't see how you really can replace an agile routing protocol by a central registry. > > Perhaps I am misunderstanding the comment. > I hope this clarifies my thinking a bit. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From kcartwright@verisign.com Tue Mar 24 16:36:21 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E4FC3A681E for ; Tue, 24 Mar 2009 16:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EyIRGVbYk4E for ; Tue, 24 Mar 2009 16:36:20 -0700 (PDT) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by core3.amsl.com (Postfix) with ESMTP id 14AB03A682A for ; Tue, 24 Mar 2009 16:36:20 -0700 (PDT) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id n2ONBeo3013343; Tue, 24 Mar 2009 16:11:40 -0700 Received: from oly1wnexcb01.vcorp.ad.vrsn.com ([10.55.13.56]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 16:37:08 -0700 Received: from OLY1WNEXCB04.vcorp.ad.vrsn.com ([10.55.13.59]) by oly1wnexcb01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 16:37:08 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 24 Mar 2009 16:37:05 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [drinks] Some comments on the use-cases draft Thread-Index: Acmr/Gq6DpRKIihHT7Sxlydd4c7QwgA29Duw References: <49A7063C.6080503@nic.at><9AAEDF491EF7CA48AB587781B8F5D7C601A1ADA6@srvxchg3.cablelabs.com> <49C7FBC8.90305@nic.at> From: "Cartwright, Kenneth" To: "Otmar Lendl" , "Sumanth Channabasappa" X-OriginalArrivalTime: 24 Mar 2009 23:37:08.0756 (UTC) FILETIME=[729D4540:01C9ACD9] Cc: IETF DRINKS WG Subject: Re: [drinks] Some comments on the use-cases draft X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 23:36:21 -0000 Sorry for the delayed response, am having issues with my laptop her in San Fran. The File Processor is a *very* small piece of software, so no design document was necessary (i.e. the code is so small that the code itself and the javadoc comments therein are best approach to documenting it). However, the Technical Requirements Document describes, in detail, the behavior of the File Processor. As far as the source control goes: 1) Unfortunately, the File Processor code lives within the NRD-PS Project within our Subversion repository. What we should have done was introduce a new project, maybe called "NRD/NIR Input File Processor". 2) I believe what we should do is take the current File Processor code base out of the NRD-PS project and create a new CM repository project. 3) Your additions and changes to the File Processor would then be made in that repository. Ken -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Otmar Lendl Sent: Monday, March 23, 2009 5:15 PM To: Sumanth Channabasappa Cc: IETF DRINKS WG Subject: Re: [drinks] Some comments on the use-cases draft Sumanth, Just some quick notes, I hope you have a good session tomorrow. It's unlikely that I can join via Jabber. Sumanth Channabasappa wrote: > Thanks for your comments. I guess we - as in the design team - were > expecting more feedback prior to responding, or we got busy.=20 Let's hope where will be a discussion here. > ---- > * This is a telco design. Basic bell-head thinking with only some > marginal > sprinkling of Internet ideas. This is a document which describes how one > might carry over the telco provisioning, interconnection and call > routing approaches to the VoIP world. >=20 > All fine and good, but to be provocative: why is this an IETF WG > document > and not an ITU-T, OASIS or 3GPP paper? The role model, the actors and a > most use-cases are almost straight from the PSTN playbook. > [S] Can you provide specific use cases that you would have rather liked > to see (in addition to your thoughts later on in the email, which help > some)?=20 Here are some scenarios: * Enterprise PBX with multiple connections to carriers, trying to optimize outgoing calls. * Any form of ad-hoc, not manually pre-configured peering. * e.g.: All PBXs of an industry sector want to peer, and authenticate based on TLS certs by some trade group. More importantly, I have this nagging feeling that most of your use-cases imply that there will be a central registry which will feed the data back into local data repositories. I don't see this as a given for the routing part. > As a note, I am not questioning your observation! The current use cases > are based on perceived industry needs (by the design team). It will be > nice to see how we can make it more relevant, if it is not. Well, given the people on the design team who are either used to utilize such a setup or provide this registry, this is not surprising. > ---- >=20 > * This is way too ambitious on one hand. Defining all this in a single > protocol and implementing the registry which actually does all these > things is a herculean task. >=20 > Layering, folks. Layering. > [S] Ah! Keep in mind that this is a requirements document. We can > prioritize and specify protocol phases if the WG feels that this is too > much at once! :) You're requirements are based on a design decision (all data exchange is via the same protocol and possibly all via a registry). Take that away, e.g. "do the TN -> routing group mapping via a registry, but do the routing peer2peer between connected SSPs", and you get instant layering. And then it isn't "protocol phases", but two completely distinct protocols. > ---- >> SED Record: A SED Record contains much of the session > establishment >> data or a 'redirect' to another registry where the session >> establishment data can be discovered. SED Records types > supported >> are NAPTRs, CNAME, DNAME, and NS Records. >=20 > What about TLS parameters, Source IP addresses of SBEs, Codec > constraints, > SIP profiles, ... >=20 > This is far too DNS focussed. > [S] I agree. We need to consider parameters specified in Section 3.3, > RFC5486. See Alex's draft and also draft-hancock-sip-interconnect-guidelines-00. > ---- >=20 >> o Registries are the authoritative source for provisioned session >> establishment data (SED) and related information. >=20 > Eeek. >=20 > SED includes what the next hop is. In a dynamic network, this can change > quickly as SBEs or links fail, congestion makes paths unavailable or > some > business decisions make a different path more attractive. >=20 > I cannot fathom that >=20 > * these real-time routing information is exchanged via the registry, >=20 > * carriers outsource the business decision part of the call routing > algorithm to third parties. > [S] In the current paradigm (within the I-D), the registry will need to > be updated to reflect changes, which is then propagated to local data > repositories. The provisioned data should ideally be resilient to > hiccups (e.g., contain multiple routes to account for backups, > prioritization). Isn't the ability to dynamically provision data one of > the reasons why we want to work on this? I think we're back to the fundamental outlook towards this problem. One can look at the problem space from the telco point of view, where you have a relatively static network. Each border element is hardcore telco-grade equipment, inherently redundant and likely clustered as well. You don't plan that such a border element is unavailable in toto often. In the Internet world, this is a bit like HTTP and email: You usually don't change the DNS for simple fallback scenarios: you might have a few A (or MX) records, but the real redundancy is provides by load-balancers and heavy duty server machinery. SIP with the NAPTR/SRV lookups uses the same approach: on failure of the primary element, fall back to others. Once you go to the Internet Routing layer, this changes. If a router (or link) fails, the BGP session goes down and another path has to be selected. There is no "hmm, let's try this other MAC address, maybe there is a standby device." You don't do VRRP or any of these cluster-features in the routing space. On failure, you just let the routing protocol select a new path. Instantly. This is a bit like the RAID principle: you don't build a single, super-reliable disk, but combine cheap disks with a bit intelligence and you get good reliability. Now, the question is, what's the better routing model for what we are trying to achieve here? The original SIP design is simple: directly connect to the destination network via the common IP transport network. There is no multi-hop routing problem on the SIP layer. Failures in the transmission layers are covered by the IP routing protocols, so SIP never needed to care. SRV records suffice to loadbalance/fallback within the destination network. All fine and dandy. Except that this is not what happened in the real world. There is no single common IP network for VoIP. There are a bunch of interconnection networks and private peering links in addition to the public Internet. VoIP routing is thus a multihop routing problem. And for a multihop routing problem, the NAPTR/SRV fallback mechanisms are NOT ENOUGH. Example network diagram: A -- B -- C -- D \ / - E -- F A has paths ABCD and AEFD to D. Now assume A is using the ABCD path. INVITES are passed along, but suddenly C fails to be reachable by B. B can try all the other SRV records of C it finds, but it just can't pass on the call. A has to learn of this link failure and route to E instead. Yes, it is possible to do this with a central registry: all players need keep it up to date in real-time with respect to link/SBE/DBE failures. That registry needs to have a complete map and state of all links between all SSPs in order to play the routing oracle. (How C could tell the registry that it just lost power to it's datacenter, and thus can't act as a transit network any more is beyond me.) This is a monopoly position and a single point of failure for the whole Voice Network. Or, alternatively, you go for the BGP model and let B tell A "sorry, I can't reach C and D any more". Directly from border-element to border-element. You might say that such link failures are rare. Maybe they are if you think only of real large carriers and their 5-nines equipment. That's not necessarily all there is to VoIP. There are enough pure-VoIP startups, and (at least here in Austria) a good number of local cable networks are providing IP and VoIP services as well. Corporate PBXs are another example. It's a question of where you put in your redundancy: fortify the nodes or prepare for failed nodes with a really dynamic routing protocol. I just can't see how you really can replace an agile routing protocol by a central registry. >=20 > Perhaps I am misunderstanding the comment. >=20 I hope this clarifies my thinking a bit. /ol --=20 // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks From kcartwright@verisign.com Tue Mar 24 16:51:08 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A224E3A684F for ; Tue, 24 Mar 2009 16:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8gSIhPNNXAa for ; Tue, 24 Mar 2009 16:51:06 -0700 (PDT) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id CAD503A67EE for ; Tue, 24 Mar 2009 16:51:06 -0700 (PDT) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n2ONpuGt018647; Tue, 24 Mar 2009 16:51:56 -0700 Received: from oly1wnexcb02.vcorp.ad.vrsn.com ([10.55.13.57]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 16:51:55 -0700 Received: from OLY1WNEXCB04.vcorp.ad.vrsn.com ([10.55.13.59]) by oly1wnexcb02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 16:51:55 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 24 Mar 2009 16:51:53 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [drinks] Some comments on the use-cases draft Thread-Index: Acmr/Gq6DpRKIihHT7Sxlydd4c7QwgA29DuwAACvb0A= References: <49A7063C.6080503@nic.at><9AAEDF491EF7CA48AB587781B8F5D7C601A1ADA6@srvxchg3.cablelabs.com><49C7FBC8.90305@nic.at> From: "Cartwright, Kenneth" To: "Cartwright, Kenneth" , "Otmar Lendl" , "Sumanth Channabasappa" X-OriginalArrivalTime: 24 Mar 2009 23:51:55.0601 (UTC) FILETIME=[83371410:01C9ACDB] Cc: IETF DRINKS WG Subject: Re: [drinks] Some comments on the use-cases draft X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 23:51:08 -0000 Sorry about this email. My laptop and Outlook instance is having issues. Needless to say, this email does not relate to drinks and can be ignored. Ken=20 -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Cartwright, Kenneth Sent: Tuesday, March 24, 2009 7:37 PM To: Otmar Lendl; Sumanth Channabasappa Cc: IETF DRINKS WG Subject: Re: [drinks] Some comments on the use-cases draft Sorry for the delayed response, am having issues with my laptop her in San Fran. The File Processor is a *very* small piece of software, so no design document was necessary (i.e. the code is so small that the code itself and the javadoc comments therein are best approach to documenting it). However, the Technical Requirements Document describes, in detail, the behavior of the File Processor. As far as the source control goes: 1) Unfortunately, the File Processor code lives within the NRD-PS Project within our Subversion repository. What we should have done was introduce a new project, maybe called "NRD/NIR Input File Processor". 2) I believe what we should do is take the current File Processor code base out of the NRD-PS project and create a new CM repository project. 3) Your additions and changes to the File Processor would then be made in that repository. Ken -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Otmar Lendl Sent: Monday, March 23, 2009 5:15 PM To: Sumanth Channabasappa Cc: IETF DRINKS WG Subject: Re: [drinks] Some comments on the use-cases draft Sumanth, Just some quick notes, I hope you have a good session tomorrow. It's unlikely that I can join via Jabber. Sumanth Channabasappa wrote: > Thanks for your comments. I guess we - as in the design team - were > expecting more feedback prior to responding, or we got busy.=20 Let's hope where will be a discussion here. > ---- > * This is a telco design. Basic bell-head thinking with only some > marginal > sprinkling of Internet ideas. This is a document which describes how one > might carry over the telco provisioning, interconnection and call > routing approaches to the VoIP world. >=20 > All fine and good, but to be provocative: why is this an IETF WG > document > and not an ITU-T, OASIS or 3GPP paper? The role model, the actors and a > most use-cases are almost straight from the PSTN playbook. > [S] Can you provide specific use cases that you would have rather liked > to see (in addition to your thoughts later on in the email, which help > some)?=20 Here are some scenarios: * Enterprise PBX with multiple connections to carriers, trying to optimize outgoing calls. * Any form of ad-hoc, not manually pre-configured peering. * e.g.: All PBXs of an industry sector want to peer, and authenticate based on TLS certs by some trade group. More importantly, I have this nagging feeling that most of your use-cases imply that there will be a central registry which will feed the data back into local data repositories. I don't see this as a given for the routing part. > As a note, I am not questioning your observation! The current use cases > are based on perceived industry needs (by the design team). It will be > nice to see how we can make it more relevant, if it is not. Well, given the people on the design team who are either used to utilize such a setup or provide this registry, this is not surprising. > ---- >=20 > * This is way too ambitious on one hand. Defining all this in a single > protocol and implementing the registry which actually does all these > things is a herculean task. >=20 > Layering, folks. Layering. > [S] Ah! Keep in mind that this is a requirements document. We can > prioritize and specify protocol phases if the WG feels that this is too > much at once! :) You're requirements are based on a design decision (all data exchange is via the same protocol and possibly all via a registry). Take that away, e.g. "do the TN -> routing group mapping via a registry, but do the routing peer2peer between connected SSPs", and you get instant layering. And then it isn't "protocol phases", but two completely distinct protocols. > ---- >> SED Record: A SED Record contains much of the session > establishment >> data or a 'redirect' to another registry where the session >> establishment data can be discovered. SED Records types > supported >> are NAPTRs, CNAME, DNAME, and NS Records. >=20 > What about TLS parameters, Source IP addresses of SBEs, Codec > constraints, > SIP profiles, ... >=20 > This is far too DNS focussed. > [S] I agree. We need to consider parameters specified in Section 3.3, > RFC5486. See Alex's draft and also draft-hancock-sip-interconnect-guidelines-00. > ---- >=20 >> o Registries are the authoritative source for provisioned session >> establishment data (SED) and related information. >=20 > Eeek. >=20 > SED includes what the next hop is. In a dynamic network, this can change > quickly as SBEs or links fail, congestion makes paths unavailable or > some > business decisions make a different path more attractive. >=20 > I cannot fathom that >=20 > * these real-time routing information is exchanged via the registry, >=20 > * carriers outsource the business decision part of the call routing > algorithm to third parties. > [S] In the current paradigm (within the I-D), the registry will need to > be updated to reflect changes, which is then propagated to local data > repositories. The provisioned data should ideally be resilient to > hiccups (e.g., contain multiple routes to account for backups, > prioritization). Isn't the ability to dynamically provision data one of > the reasons why we want to work on this? I think we're back to the fundamental outlook towards this problem. One can look at the problem space from the telco point of view, where you have a relatively static network. Each border element is hardcore telco-grade equipment, inherently redundant and likely clustered as well. You don't plan that such a border element is unavailable in toto often. In the Internet world, this is a bit like HTTP and email: You usually don't change the DNS for simple fallback scenarios: you might have a few A (or MX) records, but the real redundancy is provides by load-balancers and heavy duty server machinery. SIP with the NAPTR/SRV lookups uses the same approach: on failure of the primary element, fall back to others. Once you go to the Internet Routing layer, this changes. If a router (or link) fails, the BGP session goes down and another path has to be selected. There is no "hmm, let's try this other MAC address, maybe there is a standby device." You don't do VRRP or any of these cluster-features in the routing space. On failure, you just let the routing protocol select a new path. Instantly. This is a bit like the RAID principle: you don't build a single, super-reliable disk, but combine cheap disks with a bit intelligence and you get good reliability. Now, the question is, what's the better routing model for what we are trying to achieve here? The original SIP design is simple: directly connect to the destination network via the common IP transport network. There is no multi-hop routing problem on the SIP layer. Failures in the transmission layers are covered by the IP routing protocols, so SIP never needed to care. SRV records suffice to loadbalance/fallback within the destination network. All fine and dandy. Except that this is not what happened in the real world. There is no single common IP network for VoIP. There are a bunch of interconnection networks and private peering links in addition to the public Internet. VoIP routing is thus a multihop routing problem. And for a multihop routing problem, the NAPTR/SRV fallback mechanisms are NOT ENOUGH. Example network diagram: A -- B -- C -- D \ / - E -- F A has paths ABCD and AEFD to D. Now assume A is using the ABCD path. INVITES are passed along, but suddenly C fails to be reachable by B. B can try all the other SRV records of C it finds, but it just can't pass on the call. A has to learn of this link failure and route to E instead. Yes, it is possible to do this with a central registry: all players need keep it up to date in real-time with respect to link/SBE/DBE failures. That registry needs to have a complete map and state of all links between all SSPs in order to play the routing oracle. (How C could tell the registry that it just lost power to it's datacenter, and thus can't act as a transit network any more is beyond me.) This is a monopoly position and a single point of failure for the whole Voice Network. Or, alternatively, you go for the BGP model and let B tell A "sorry, I can't reach C and D any more". Directly from border-element to border-element. You might say that such link failures are rare. Maybe they are if you think only of real large carriers and their 5-nines equipment. That's not necessarily all there is to VoIP. There are enough pure-VoIP startups, and (at least here in Austria) a good number of local cable networks are providing IP and VoIP services as well. Corporate PBXs are another example. It's a question of where you put in your redundancy: fortify the nodes or prepare for failed nodes with a really dynamic routing protocol. I just can't see how you really can replace an agile routing protocol by a central registry. >=20 > Perhaps I am misunderstanding the comment. >=20 I hope this clarifies my thinking a bit. /ol --=20 // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks