IETF Logo Mail Archive

Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09

Simon Perreault <simon.perreault@viagenie.ca> Mon, 07 January 2013 16:13 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C6C21F8960 for <pcp@ietfa.amsl.com>; Mon, 7 Jan 2013 08:13:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b04zQsTRMZ-f for <pcp@ietfa.amsl.com>; Mon, 7 Jan 2013 08:13:53 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1C521F8967 for <pcp@ietf.org>; Mon, 7 Jan 2013 08:13:53 -0800 (PST)
Received: from porto.nomis80.org (85-169-40-152.rev.numericable.fr [85.169.40.152]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6EE944039E; Mon, 7 Jan 2013 11:13:52 -0500 (EST)
Message-ID: <50EAF43F.1020701@viagenie.ca>
Date: Mon, 07 Jan 2013 17:13:51 +0100
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Alain Durand <adurand@juniper.net>
References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <82256834F867D44BBB8E49E40D5448BB065955DC@BL2PRD0510MB386.namprd05.prod.outlook.com> <50EA9BF9.2010302@viagenie.ca> <82256834F867D44BBB8E49E40D5448BB065A432B@BL2PRD0510MB386.namprd05.prod.outlook.com>
In-Reply-To: <82256834F867D44BBB8E49E40D5448BB065A432B@BL2PRD0510MB386.namprd05.prod.outlook.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: "<pcp@ietf.org>" <pcp@ietf.org>
Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2013 16:13:54 -0000

Le 2013-01-07 16:55, Alain Durand a écrit :
>>> Also, when ports are running low, connections may be delayed until a new port set is acquired.
>>
>> This is up to the PCP client to figure out. The same concern applies to the MAP opcode.
>
> Not sure. with MAP opcode, the logic is that it is the user application that requests the port, in doing so, it knows that it may have to wait a little.
> With the option described in the draft, the logic is that the CPE makes the request for an additional set of ports, unbeknown to the application...

There is no such difference. A MAP_PORT_SET request may be made either 
by an individual application or by the operating system, just like a MAP 
request.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

v2.23.0 | Report a Bug | By Email