From petithug@acm.org Tue Aug 9 16:01:49 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D627811E8070 for ; Tue, 9 Aug 2011 16:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IbtFRbMvIEI for ; Tue, 9 Aug 2011 16:01:49 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id DA45B11E809E for ; Tue, 9 Aug 2011 16:01:48 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:a800:4ff:fe00:a04] (unknown [IPv6:2001:470:1f05:616:a800:4ff:fe00:a04]) by implementers.org (Postfix) with ESMTPS id 5DF46202C8 for ; Wed, 10 Aug 2011 00:59:01 +0200 (CEST) Message-ID: <4E41BC77.6030904@acm.org> Date: Tue, 09 Aug 2011 16:02:15 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] PVP validation X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 23:01:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 During my presentation in Quebec City, I promised more explanations on the PVP slide. Let's imagine that an Enterprise is using ProviderA to route its calls (e.g. with a SIP trunk). The following diagram shows what happen in this case. Note that the RELOAD overlay is shown as one network element as the only feature that we care about here is its distributed database and that I used different lines symbols for different protocols: PhoneA Enterprise ProviderA RELOAD ProviderB PhoneB | | Store | | | | 1 | |---------------------------->| Store | | 2 | | | Store |<------------| | 3 | | |------------->| | | : : : : : : | INVITE | | | | | 4 |==========>| INVITE | | | | 5 | |=============>| SETUP | | | 6 | | |~~~~~~~~~~~~~~~~~~~~~~~~~~~>| INVITE | 7 | | | | |========>| : : : : : BYE : 8 | | | | DISC |<========| 9 | | BYE |<~~~~~~~~~~~~~~~~~~~~~~~~~~~| | 10 | BYE |<=============| | | | 11 |<==========| | Fetch | | | 12 | | Fetch |------------->| | | 13 | |---------------------------->| | | | | | ValExchange | | | 14 | | ValExchange |:::::::::::::::::::::::::::>| | | |::::::::::::::::::::::::::::::::::::::::::>| | : : : : : : | INVITE | | | | | 15 |==========>| INVITE | | | | 16 | |==========================================>| INVITE | 17 | | | | |========>| | | | | | | Independently, Enterprise and ProviderA decide to deploy VIPR, so they both register (1, 3) the same phone number for PhoneA in the RELOAD distributed database. Separately ProviderB also registers (2) the phone number of PhoneB in the RELOAD database. PhoneA makes a call (4) which is not in the route database of Enterprise, so it is proxied (5) to ProviderA. ProviderA does not have a route either, so the call is routed through the PSTN (6) to ProviderB and over IP to PhoneB (7). After some time the call ends, so PhoneB sends a BYE (8) that is routed over the PSTN (9) and IP (10, 11) to PhoneA. ProviderB uploads a terminating VCR and *both* Enterprise and ProviderA upload an originating VCR, which *both* will trigger the establishment of a PVP connection and a ValExchange transaction. In the example above both PVP transactions succeed because the text now says that the terminating VCR must not be removed until the end of the 48 hours period, even if a PVP transaction succeeded. In this case, the route stored by Enterprise is used for the next call (15, 16, 17) because it is the first call agent in the path, but if for some reason this route would fail the call would still be VoIP end to end, thanks to the route stored in ProviderA. Without this rule, we cannot predict which one of the two ValExchange transaction will start first (and we do not want create a race to who's win by using priorities), so we now are sure that it is always the closer route to the caller that will be used and that the others routes will be used as backup. Note that if only ProviderA route is created (as it would happen in 50% of the case with the old text), the Enterprise route will still be created on the second call. Using the new text permits to have only one PSTN call (from the point of view of the Enterprise) and maximize the number of backup routes at all times (we probably want to set the ticket expiration value to the same for all VIPR servers to be sure that the next PSTN call will revalidate all the routes). Now let switch to the scenario in the other direction. PhoneA Enterprise ProviderA RELOAD ProviderB PhoneB | | Store | | | | 1 | |---------------------------->| Store | | 2 | | | Store |<------------| | 3 | | |------------->| | | : : : : : : | | | | | INVITE | 4 | | | | SETUP |<========| 5 | | INVITE |<===========================| | 6 | INVITE |<=============| | | | 7 |<==========| | | | | : BYE : : : : : 8 |==========>| BYE | | | | 9 | |=============>| DISC | | | 10 | | |~~~~~~~~~~~~~~~~~~~~~~~~~~~>| BYE | 11 | | | | Fetch |========>| 12 | | | |<------------| | | | | | ValExchange | | 13 | | |<:::::::::::::::::::::::::::| | | | | | ValExchange | | 14 | |<::::::::::::::::::::::::::::::::::::::::::| | : | : : : INVITE : 15 | | | | INVITE |<========| 16 | | INVITE |<===========================| | 17 | INVITE |<============ | | | | 18 |<==========| | | INVITE | | 19 | |<==========================================| | | INVITE | | | | | 20 |x==========| | | | | | | | | | | The first 3 steps are identical to the first diagram, but now PhoneB calls PhoneA, call that goes through the PSTN and reaches ProviderA before Enterprise (4, 5, 6,7). The call ends the same way than in the previous diagram (8, 9, 10, 11), excepted that now it is ProviderB that initiates the verification. When it fetches the Node-Ids responsible for PhoneA (12), it receives two, which is not an abnormal case. As per the rules in VIPR, it will initiates a PVP connection to both of them, but what is new is that *both* will succeed. Per the current rules, only the last one will be kept, but again there is a 50% chance that the route kept is not the best. Instead I suggest to keep *both* and to use *both* for the subsequent call, by forking it to the two destinations (15, 16 and 19). In best case, both requests will reach PhoneA (17, 18, 20), but the second will be rejected (20), thanks to the "Merged Requests" rule in RFC 3261 section 8.2.2. An additional problem that need to be fixed in the spec is that we need to clearly defines which SIP error codes are used to simply signal that the route does not work at the time of the call, and which one are used to remove a route from the VIPR database. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk5BvHUACgkQ9RoMZyVa61c41ACdHiPnJJp4Lejqj7ix7fdUcPls z+oAnRuFEtjy3T+C70jn2YvxUDLKLvak =478+ -----END PGP SIGNATURE----- From gonzalo.camarillo@ericsson.com Wed Aug 10 23:40:21 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992EF21F8726 for ; Wed, 10 Aug 2011 23:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.589 X-Spam-Level: X-Spam-Status: No, score=-106.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okwkTu-EseEG for ; Wed, 10 Aug 2011 23:40:21 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id D54BC21F8713 for ; Wed, 10 Aug 2011 23:40:20 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-7b-4e43797536cd Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 32.CD.09774.579734E4; Thu, 11 Aug 2011 08:40:53 +0200 (CEST) Received: from [131.160.126.254] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Thu, 11 Aug 2011 08:40:53 +0200 Message-ID: <4E437974.5080207@ericsson.com> Date: Thu, 11 Aug 2011 09:40:52 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: vipr@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Thu, 11 Aug 2011 08:07:53 -0700 Subject: [VIPR] Discussing the VIPR-related RELOAD drafts in the VIPR WG X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 06:40:21 -0000 Folks, in Quebec, we were asked where to discuss the following drafts: http://tools.ietf.org/html/draft-petithuguenin-vipr-reload-usage-02 http://tools.ietf.org/html/draft-petithuguenin-p2psip-proportional-quota-01 Given that both of them relate to VIPR and that the P2PSIP WG is currently focusing on other extensions (in addition to getting the RELOAD spec published), these drafts will be discussed in the VIPR WG from now on. In any case, the drafts will make sure they are reviewed by the P2PSIP WG at an appropriate point in the process. Cheers, Gonzalo From petithug@acm.org Fri Aug 12 14:25:43 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670C321F877F for ; Fri, 12 Aug 2011 14:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTZLwNVTT+ea for ; Fri, 12 Aug 2011 14:25:42 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id ABF5621F87D9 for ; Fri, 12 Aug 2011 14:25:37 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id E9420202C8 for ; Fri, 12 Aug 2011 23:22:46 +0200 (CEST) Message-ID: <4E459A74.8090205@acm.org> Date: Fri, 12 Aug 2011 14:26:12 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] Phone number stored 3 times in the overlay X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 21:25:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 During the VIPR session in Quebec City we talked a little bit about the fact that the VIPR server had to store each number 3 times in the overlay. Because each copy is itself replicated 3 times by the CHORD-OVERLAY plugin, we now have 9 copies. The slide was originally to present the voting algorithm used when not all 3 copies matches but the conversations moved to why we need 3 copies. My proposal would be to drop the requirement for the 3 copies from VIPR, but to add the requirement that the node requesting the phone number MUST also fetch (or stat) the 2 additional replicas and use the value that matches at least one other copy (using a majority vote prevents a rogue peer to block the access to the phone numbers currently stored here). If not all 3 copies are equals, then an incident must be logged. If there is no subsequent discussion on this in the 2 next weeks, I will modify the specifications accordingly. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk5FmnMACgkQ9RoMZyVa61doQwCgjj6mpbHqi9obtkfSuA+OeYCK aDMAnjTmHuB4ekDzC605RyTFc/p+xh0U =25zf -----END PGP SIGNATURE----- From D.Malas@cablelabs.com Mon Aug 22 12:48:47 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3F621F8C89 for ; Mon, 22 Aug 2011 12:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.462 X-Spam-Level: X-Spam-Status: No, score=-100.462 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3jAeYg90AFX for ; Mon, 22 Aug 2011 12:48:47 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0DADD21F8C31 for ; Mon, 22 Aug 2011 12:48:44 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p7MJnmjo008801 for ; Mon, 22 Aug 2011 13:49:48 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Mon, 22 Aug 2011 13:49:48 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 22 Aug 2011 13:49:48 -0600 From: Daryl Malas To: "vipr@ietf.org" Date: Mon, 22 Aug 2011 13:49:47 -0600 Thread-Topic: [VIPR] 81st IETF: ViPR Meeting Notes Thread-Index: AcxhBKY8hu4pLUC6SPiGRQpa35rg5Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA780EFB1C297dmalascablelabscom_" MIME-Version: 1.0 X-Approved: ondar Subject: [VIPR] 81st IETF: ViPR Meeting Notes X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 19:48:47 -0000 --_000_CA780EFB1C297dmalascablelabscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, The ViPR meeting notes from the 81st IETF meeting in Quebec have been poste= d and are available here: http://www.ietf.org/proceedings/81/minutes/vipr.txt There are a number of unanswered questions and action items in these notes,= so please review and provide feedback to the mailing list. Regards, Daryl ViPR Co-chair --_000_CA780EFB1C297dmalascablelabscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,

The ViPR meeting notes from the 81st IETF meeting in Quebec have been= posted and are available here:


There are a number of u= nanswered questions and action items in these notes, so please review and p= rovide feedback to the mailing list.

Regards,

Daryl
ViPR Co-chair
--_000_CA780EFB1C297dmalascablelabscom_-- From D.Malas@cablelabs.com Mon Aug 29 13:23:10 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9248621F8D04 for ; Mon, 29 Aug 2011 13:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.533 X-Spam-Level: X-Spam-Status: No, score=-99.533 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtiJgI7jVW2S for ; Mon, 29 Aug 2011 13:23:09 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9C81721F8D06 for ; Mon, 29 Aug 2011 13:23:09 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p7TKOYPm024648 for ; Mon, 29 Aug 2011 14:24:34 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Mon, 29 Aug 2011 14:24:34 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 29 Aug 2011 14:24:33 -0600 From: Daryl Malas To: "vipr@ietf.org" Date: Mon, 29 Aug 2011 14:24:32 -0600 Thread-Topic: [VIPR] Calling for Design Team Volunteers Thread-Index: Acxmiam92RCPh+cJRA2qsHzB470c+g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA8151A01C775dmalascablelabscom_" MIME-Version: 1.0 X-Approved: ondar Subject: [VIPR] Calling for Design Team Volunteers X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 20:23:10 -0000 --_000_CA8151A01C775dmalascablelabscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, We need to make progress on these drafts, and Marc and Cullen have diligent= ly provided some recent updates. In order to meet our working group object= ives, I am looking for people who are willing to meet/discuss/review on a m= ore regular basis. (Note: All work as a result of this effort will be revi= ewed during upcoming working group sessions and on the mailing list.) Plea= se send me an email indicating your interest in participating. If we do no= t have a substantial willingness to work on these drafts, then we will defe= r to our area directors as to the best next steps. Please send me your int= erest in participating by September 9th. Let us know if you have any questions. Regards, Daryl (ViPR Co-Chair) --_000_CA8151A01C775dmalascablelabscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,

We need to make progress on these drafts, and Marc and Cullen have di= ligently provided some recent updates.  In order to meet our working g= roup objectives, I am looking for people who are willing to meet/discuss/re= view on a more regular basis.  (Note: All work as a result of this eff= ort will be reviewed during upcoming working group sessions and on the mail= ing list.)  Please send me an email indicating your interest in partic= ipating.  If we do not have a substantial willingness to work on these= drafts, then we will defer to our area directors as to the best next steps= .  Please send me your interest in participating by September 9th.

Let us know if you have any questions.

=
Regards,

Daryl (ViPR Co-Chair)
--_000_CA8151A01C775dmalascablelabscom_--