IETF Logo Mail Archive

Re: [pcp] last CGN requirements

<mohamed.boucadair@orange-ftgroup.com> Tue, 15 March 2011 12:12 UTC

Return-Path: <mohamed.boucadair@orange-ftgroup.com>
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 DB2EC3A6A28 for <pcp@core3.amsl.com>; Tue, 15 Mar 2011 05:12:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.023
X-Spam-Level:
X-Spam-Status: No, score=-2.023 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 NiiJ7kgHg4sA for <pcp@core3.amsl.com>; Tue, 15 Mar 2011 05:12:50 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id C6AA33A694E for <pcp@ietf.org>; Tue, 15 Mar 2011 05:12:49 -0700 (PDT)
Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 1424B3B4300; Tue, 15 Mar 2011 13:14:13 +0100 (CET)
Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id F2406384057; Tue, 15 Mar 2011 13:14:12 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Tue, 15 Mar 2011 13:14:12 +0100
From: mohamed.boucadair@orange-ftgroup.com
To: Francis Dupont <Francis.Dupont@fdupont.fr>, "pcp@ietf.org" <pcp@ietf.org>
Date: Tue, 15 Mar 2011 13:14:11 +0100
Thread-Topic: [pcp] last CGN requirements
Thread-Index: Acvi+oeJMbP5aOqLTRq6SOVByadhhAADuvHA
Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DB02BCB@PUEXCB1B.nanterre.francetelecom.fr>
References: <201103151019.p2FAJmhk073794@givry.fdupont.fr>
In-Reply-To: <201103151019.p2FAJmhk073794@givry.fdupont.fr>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.15.113021
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 12:12:50 -0000

Hi all,

REQ-6 is an operational requirement which require more elaboration: e.g., how an address pool is defined? Is there any hold-timer for the re-use of the address pool?

For operational requirements, I would prefer having something as what is documented in http://tools.ietf.org/html/draft-xu-behave-stateful-nat-standby-06.

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."


Cheers,
Med 

-----Message d'origine-----
De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Francis Dupont
Envoyé : mardi 15 mars 2011 11:20
À : pcp@ietf.org
Objet : [pcp] last CGN requirements

Printing the new base-07, I am reading the new CGN requirement draft
(named draft-ietf-behave-lsn-requirements-01.txt but LSN was replaced
by CGN everywhere at the exception of the title).
I can get:

   REQ-6:  When a CGN loses state (due to a crash, reboot, failover to a
      cold standby, etc.), it MUST start using a different external
      address pool.

   Justification:  This is necessary in order to prevent collisions
      between old and new mappings and sessions.  It ensures that all
      established sessions are broken instead of redirected to a
      different peer.  The previous address pool MAY of course be reused
      after a second loss of state.

Three comments:
 - the MUST applies to all mappings: static, explicit dynamic (i.e.,
  instantiated by PCP) and implicit dynamic.

 - it does not say something about the use of stable/persistent storage
  to remove the condition (i.e., the when).

 - it is a pure operational requirement, for instance the MAY does not
  make sense from a security point of view for long term mappings,
  i.e., static or explicit dynamic.

There are other interesting points (REQ-1 for instance) but IMHO it is
unfinished: logging section does not use the fact EIM is required for
instance.

Regards

Francis.Dupont@fdupont.fr

PS: Simon, I believe you want more comments?
_______________________________________________
pcp mailing list
pcp@ietf.org
https://www.ietf.org/mailman/listinfo/pcp

v2.23.0 | Report a Bug | By Email