[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