Re: [pcp] section 8

Francis Dupont <Francis.Dupont@fdupont.fr> Sat, 15 October 2011 11:48 UTC

Return-Path: <Francis.Dupont@fdupont.fr>
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 8444721F8B1E for <pcp@ietfa.amsl.com>; Sat, 15 Oct 2011 04:48:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.5
X-Spam-Level:
X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0D+c9EK3vH80 for <pcp@ietfa.amsl.com>; Sat, 15 Oct 2011 04:48:39 -0700 (PDT)
Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 9059621F8AD2 for <pcp@ietf.org>; Sat, 15 Oct 2011 04:48:38 -0700 (PDT)
Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p9FBljtN031911; Sat, 15 Oct 2011 13:47:47 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr)
Message-Id: <201110151147.p9FBljtN031911@givry.fdupont.fr>
From: Francis Dupont <Francis.Dupont@fdupont.fr>
To: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
In-reply-to: Your message of Fri, 14 Oct 2011 23:17:43 -0000. <C0E0A32284495243BDE0AC8A066631A80C19635B@szxeml526-mbx.china.huawei.com>
Date: Sat, 15 Oct 2011 13:47:45 +0200
Sender: Francis.Dupont@fdupont.fr
Cc: "pcp@ietf.org" <pcp@ietf.org>
Subject: Re: [pcp] section 8
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: Sat, 15 Oct 2011 11:48:39 -0000

 In your previous mail you wrote:

   Hi,
   In section 8, it reads:
     "It is REQUIRED that the PCP-controlled device assign the same
      external IP address to PCP-created explicit dynamic mappings and to
      implicit dynamic mappings for a given Internal Host.  In the absence
      of a PCP option indicating otherwise, it is REQUIRED that PCP-created
      explicit dynamic mappings be assigned the same external IP address."
   It is not consistent with what we have discussed in the mailing list below. And i
  t is a bit ambiguous in reading.
   
   How about changing the second sentence from on of the 4 candidates as below?
   
   Alternative 1:
   PCP client should request same external IP address for an application if there is
   already any existing explicit mapping for that application.
   
=> the section 8 rule is per subscriber+host so the alternative should be too.

   Alternative 2:
   PCP client should request the same external IP address if there are existing expl
  ict mappings, unless there is explicit reasons of not doing so, e.g. http://tools.
  ietf.org/html/draft-penno-pcp-zones-00
   
=> same issue

   Alternative 3:
   It is indicated by the PCP client that PCP-created explicit dynamic mappings be a
  ssigned the same external IP address, unless there are explicit reasons of not doi
  ng so, e.g. http://tools.ietf.org/html/draft-penno-pcp-zones-00"
   
=> same issue

   Alternative 4:
   It is indicated by the PCP client that PCP-created explicit dynamic mappings be a
  ssigned the same external IP address, unless a PCP option indicates different exte
  rnal IP address
   
=> same issue   
   
I can't see the problem, the text says all mappings (even there is nothing
about static mappings, is there a problem to add them?) get the same external
IP address if there is no option indicating otherwise.
BTW IWFs work far better if the affinity is per subscriber.

IMHO the best should be to make the affinity larger, i.e., per subscriber
and for all mappings, but at a lower level, i.e., with a RECOMMEND/SHOULD
in place of the current REQUIRE/MUST.

Regards

Francis.Dupont@fdupont.fr