Re: [pcp] last CGN requirements

Simon Perreault <simon.perreault@viagenie.ca> Tue, 15 March 2011 13:03 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: pcp@core3.amsl.com
Delivered-To: pcp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06C743A6D10 for <pcp@core3.amsl.com>; Tue, 15 Mar 2011 06:03:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level:
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001]
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 gYJ-WWrlMz4Y for <pcp@core3.amsl.com>; Tue, 15 Mar 2011 06:03:04 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id AE8313A6BC3 for <pcp@ietf.org>; Tue, 15 Mar 2011 06:03:04 -0700 (PDT)
Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EB83621C78 for <pcp@ietf.org>; Tue, 15 Mar 2011 09:04:28 -0400 (EDT)
Message-ID: <4D7F63DC.3060703@viagenie.ca>
Date: Tue, 15 Mar 2011 09:04:28 -0400
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7
MIME-Version: 1.0
To: pcp@ietf.org
References: <201103151019.p2FAJmhk073794@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F33C4DB02BCB@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DB02BCB@PUEXCB1B.nanterre.francetelecom.fr>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [pcp] last CGN requirements
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 15 Mar 2011 13:03:06 -0000

On 2011-03-15 08:14, mohamed.boucadair@orange-ftgroup.com wrote:
> REQ-6 is an operational requirement which require more elaboration:
> e.g., how an address pool is defined?

We understand "address pool" to have the same meaning as in RFC 4787. Do
we need to add anything?

> Is there any hold-timer for the
> re-use of the address pool?

That could be something useful to add to the document. What do you propose?

> In draft-xu-behave-stateful-nat-standby-06, you may read this
> requirement which I would like see integrated in the CGN requirement
> I-D:
> 
> "Port forwarding entries SHOULD be stored in permanent storage 
> whatever the deployed redundancy mode."

I agree with the idea, but this needs work on terminology. "Port
forwarding entry" is not defined anywhere. We could say "static NAT
mappings", but then if they are static why do they need storing? If this
would only refer to PCP mappings then it is already covered by the PCP
document. Any idea on how we can solve this?

(But please let's continue this discussion on the behave mailing list.)

Thanks,
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