[pcp] Comment on REQ-9A of LSN requirements (PCP)
"Reinaldo Penno (repenno)" <repenno@cisco.com> Tue, 21 August 2012 02:24 UTC
Return-Path: <repenno@cisco.com>
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 8A14011E80A4; Mon, 20 Aug 2012 19:24:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.359
X-Spam-Level:
X-Spam-Status: No, score=-10.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 7c6kaIoevcoA; Mon, 20 Aug 2012 19:24:50 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id CF8EC11E809A; Mon, 20 Aug 2012 19:24:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=1268; q=dns/txt; s=iport; t=1345515890; x=1346725490; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=7SBdHV1CANR2yheI8fGQKBCf6P+VtyPARXz7HQgL5M8=; b=RlCpaSnUdCuZn5a+zpKomLTUxtbyJEpKhVI4dsB0x0PVGStN4DFRgak7 kbsCfEWAVtFFCm3TzL0V4lQK0QZ5IPih7Isw3uvPfl5MO9NeKrEZO3h4W gdf7670UcK/z/OWCCSAz2IYaKUFvYvmhqbPpsJT6jLhqVHBpfnCJ4y5Kt Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAPzvMlCtJXG9/2dsb2JhbABFuluBB4InEgEnPxIBPkIlAgQOHgIHh2uZJKA6kicDlVCOLIFmgmE
X-IronPort-AV: E=Sophos;i="4.77,799,1336348800"; d="scan'208";a="113624791"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 21 Aug 2012 02:24:49 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7L2Onuj000372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Aug 2012 02:24:49 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0298.004; Mon, 20 Aug 2012 21:24:48 -0500
From: "Reinaldo Penno (repenno)" <repenno@cisco.com>
To: "pcp@ietf.org" <pcp@ietf.org>
Thread-Topic: Comment on REQ-9A of LSN requirements (PCP)
Thread-Index: AQHNf0Qj9EHhzDdBA0m9uGbHtDuTEQ==
Date: Tue, 21 Aug 2012 02:24:48 +0000
Message-ID: <CC583B5E.9473%repenno@cisco.com>
In-Reply-To: <CBD02DD4.5675%repenno@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.155.70.70]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19128.001
x-tm-as-result: No--27.330000-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <58B31ABC34AD18438D06D0F7FA90A4F5@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "behave@ietf.org" <behave@ietf.org>
Subject: [pcp] Comment on REQ-9A of LSN requirements (PCP)
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: Tue, 21 Aug 2012 02:24:50 -0000
"A. It MUST NOT permit the lifetime of a mapping to be reduced beyond its current life or be set to zero (deleted)." In the case of renumbering how a CPE that gets a new address can delete stale mappings of the previous user of that IP address? Given some of the requirements, it can not. Before mapping 'nonce' CPE/host could just send a delete all and we would rely on ingress filtering to make sure things are okay. But now with the mapping nonce the new owner of an IP address has no way of deleting the stale mappings because it does not know the nonce. If renumbering happens frequently (as in some networks as short as 30 minutes) and there are many PCP MAP mappings from each CPE/host, then soon depending on the Lifetime there will be no more resources on CGN/AFTR/Firewall due to stale mappings A possible solution would be for DHCP Server or other provisioning server to send a PCP message with THIRD_PARTY to delete all MAP mappings. But again, it does not know the nonce. Not to mention that coupling provisioning and PCP becomes a barrier for adoption. Reducing the 'lifetime' defeats the purpose of having PCP. Not sure of any solution given all requirements in place. Thanks, Reinaldo
- [pcp] PCP robustness for Rapid Recovery Dan Wing
- Re: [pcp] PCP robustness for Rapid Recovery Xiaohong Deng
- Re: [pcp] PCP robustness for Rapid Recovery Dan Wing
- Re: [pcp] PCP robustness for Rapid Recovery Stuart Cheshire
- Re: [pcp] PCP robustness for Rapid Recovery Reinaldo Penno
- Re: [pcp] PCP robustness for Rapid Recovery Xiaohong Deng
- Re: [pcp] PCP robustness for Rapid Recovery Dan Wing
- Re: [pcp] PCP robustness for Rapid Recovery Xiaohong Deng
- Re: [pcp] PCP robustness for Rapid Recovery Dan Wing
- Re: [pcp] PCP robustness for Rapid Recovery Xiaohong Deng
- [pcp] Comment on REQ-9A of LSN requirements (PCP) Reinaldo Penno (repenno)
- Re: [pcp] Comment on REQ-9A of LSN requirements (… mohamed.boucadair
- Re: [pcp] Comment on REQ-9A of LSN requirements (… Reinaldo Penno (repenno)