Re: [P2PSIP] UNSAF considerations and draft-ietf-p2psip-drr

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Mon, 24 June 2013 08:11 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: p2psip@ietfa.amsl.com
Delivered-To: p2psip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1539C21F9A70 for <p2psip@ietfa.amsl.com>; Mon, 24 Jun 2013 01:11:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.084
X-Spam-Level:
X-Spam-Status: No, score=-106.084 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 4sivdORc7xIC for <p2psip@ietfa.amsl.com>; Mon, 24 Jun 2013 01:11:42 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id B2DF221F8411 for <p2psip@ietf.org>; Mon, 24 Jun 2013 01:11:24 -0700 (PDT)
X-AuditID: c1b4fb30-b7f9e6d000002643-dd-51c7ff295344
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 64.CF.09795.92FF7C15; Mon, 24 Jun 2013 10:11:22 +0200 (CEST)
Received: from [131.160.36.49] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Mon, 24 Jun 2013 10:11:21 +0200
Message-ID: <51C7FF29.9070901@ericsson.com>
Date: Mon, 24 Jun 2013 11:11:21 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Roni Even <ron.even.tlv@gmail.com>
References: <51BEFAC4.3050302@ericsson.com> <004b01ce7026$55930650$00b912f0$@gmail.com>
In-Reply-To: <004b01ce7026$55930650$00b912f0$@gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZGfG3Vlfr//FAg/WP2S2W3DzDaPG3ndmB yWPnrLvsHkuW/GQKYIrisklJzcksSy3St0vgyph+4BFzwW3hir7frA2M//i7GDk5JARMJJof PmGEsMUkLtxbz9bFyMUhJHCKUeLijessEM5qRomufx0sIFW8AtoSV5cfZAaxWQRUJT5/OArW zSZgIbHl1n2wGlGBKIk56x6wQdQLSpyc+QQsLiKgJvF67WegOAcHM9CcR599QcLCAi4Sm47+ ARspJBAu0XL+KlgJJ9DI1odKELdJSmx50c4OYjML6ElMudrCCGHLS2x/OweqVVti+bMWlgmM QrOQLJ6FpGUWkpYFjMyrGNlzEzNz0svNNzECg/Tglt8GOxg33Rc7xCjNwaIkzvvp1K5AIYH0 xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwHa1Zs28DByrkjOFls6hOnJdOLLPZLeHVYiIk/fMbW 33ZSMuG50WIzGY5vs3wyZ/BFvTDNuiL4LeKVvFz5Md7Ljk8Fv8nxeG+827X/lbdc38PO7O7A PGa3EKNPZ0/PCp9kdnuH7Znn3xRMNj+0TVPrU571X+nQz2vP+NtzArpZ1VU3fnH2MFZiKc5I NNRiLipOBAD+1AllIAIAAA==
Cc: 'P2PSIP Mailing List' <p2psip@ietf.org>
Subject: Re: [P2PSIP] UNSAF considerations and draft-ietf-p2psip-drr
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jun 2013 08:13:15 -0000

Hi Roni,

I think the draft should discuss in more detail how a node makes the
decision of attempting to use DRR and what are the trade-offs. The case
of closed or managed networks is clear. The draft can mention that an
administrator simply configures nodes to use DRR because the
administrator knows, somehow, that it will work fine.

In open networks, the draft should discuss the trial and error system
being proposed. For example, a node without a public IP address may be
able to communicate directly with a node in the same non-public address
space. That case is not covered by the discussions about UNSAF
mechanisms. The whole point about developing ICE was that UNSAF
mechanisms do not work in many situations.

In short, this is an important interoperability issue because it relates
to when a node should use one mechanism or another. Therefore, the draft
should discuss all the implications of the proposed mechanism carefully.

Thanks,

Gonzalo



On 23/06/2013 6:28 PM, Roni Even wrote:
> Hi Gonzalo,
> Thanks for point out to RFC3424.
> How about adding to the following sentence an informative reference to
> RFC3424. Note that appendix A is not creating an UNSAF proposal but just
> mentions some methods for informational purpose.
> 
> Suggest adding to "Note that there is no foolproof way to determine if a
> peer is publically reachable, other than via out-of-band  mechanisms."  to
> 
> "Note that there is no foolproof way to determine if a peer is publically
> reachable, other than via out-of-band mechanisms. For discussion about
> issues with address evaluation also see UNSAF [RFC3424]"
> 
> I am not sure if it adds much information but it may be good to have this
> reference
> 
> Roni Even
> 
>> -----Original Message-----
>> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf
>> Of Gonzalo Camarillo
>> Sent: 17 June, 2013 3:02 PM
>> To: P2PSIP Mailing List
>> Subject: [P2PSIP] UNSAF considerations and draft-ietf-p2psip-drr
>>
>> Folks,
>>
>> Appendix A of the following draft describes how a node can obtain IP
>> addresses on which it may be reached:
>>
>> http://tools.ietf.org/html/draft-ietf-p2psip-drr-07#appendix-A
>>
>> Have you taken into account the UNSAF considerations?
>>
>> http://tools.ietf.org/html/rfc3424
>>
>> Cheers,
>>
>> Gonzalo
>> _______________________________________________
>> P2PSIP mailing list
>> P2PSIP@ietf.org
>> https://www.ietf.org/mailman/listinfo/p2psip
>