Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

Lorenzo Colitti <lorenzo@google.com> Mon, 23 February 2015 10:49 UTC

Return-Path: <lorenzo@google.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEE11A1A15 for <v6ops@ietfa.amsl.com>; Mon, 23 Feb 2015 02:49:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6NGt0z86HCk for <v6ops@ietfa.amsl.com>; Mon, 23 Feb 2015 02:49:28 -0800 (PST)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34BF61A0013 for <v6ops@ietf.org>; Mon, 23 Feb 2015 02:49:28 -0800 (PST)
Received: by iecar1 with SMTP id ar1so22264375iec.11 for <v6ops@ietf.org>; Mon, 23 Feb 2015 02:49:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=AXI9eAa0ZzAb4Ek22gcOsj8Nnf+ig0K0WhA0Bnlfm+A=; b=eLDh/nKOmI4LWDQzsTtj2Tqkykfe8QZgXUSY38xL57kGC4jccFu1UfVREdIXVKXVu/ niCxG6aO7cxavJIw+w5EZCc9Z5oZZU/kAFYjpa9d40hlI/zbGGTXDnjwbp+6x8x95iOQ DjIbBYNv+mABSkdfP2o/ib8zvuYCuLGJ4JVMyT/ms42sMbN+dVktcKLNmnz1W79Bm485 llbBY0+F56cK5ratlhGzxMbIjSkL2Q+0mHXckrJjI+wPcGHyQzlAN62aDTTdR7J3JS8N wmxnEI4gmGC74fLnhKDEjAlnqo5GnMXoAfUBgbAabXtrHpBcE+aAWcjZ6gMRQh883+oo aDVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=AXI9eAa0ZzAb4Ek22gcOsj8Nnf+ig0K0WhA0Bnlfm+A=; b=X/RgrOXOsUrOBDYS0tXDnOQNAmmRPJdc4A94QQzglxGZqe5OO7SkY4RLw6l88X0nup MQL3cfigUqFYKqCBgLGPAqWuy4X4/sQJPog6KxeGI4VwlvFjRnSU/aDTmtzcs+DbkF+0 1CoNR9514+b5UdLcmN0cED6gptXauoN7KV5pHwnC7vanAh/4Agk36dfQ44XKa/uxR/9N eW572MiywBiZ3n0d+jfD1oGnScwK1Ld+smvcwA3c5DFvsrTugLQR/JwSvS6ZTNJfPbe3 lIPyBsEeis4pIh0BOhbvEgWDlU+jliG/HnojHJTVpvgUIs/MBqsy96ZmWXEiHyNe+eG/ XMWQ==
X-Gm-Message-State: ALoCoQnFgqONohS8S7RcxddEIWYyB+wYl5GiMDKOsfUiIzwXcZ3BI4Vf40fKVOOK9v2Js0JQtyyr
X-Received: by 10.107.170.220 with SMTP id g89mr12673270ioj.31.1424688567310; Mon, 23 Feb 2015 02:49:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.33.104 with HTTP; Mon, 23 Feb 2015 02:49:07 -0800 (PST)
In-Reply-To: <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup>
References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <alpine.DEB.2.02.1502201513320.4007@uplift.swm.pp.se> <787AE7BB302AE849A7480A190F8B933004912254@OPEXCLILM23.corporate.adroot.infra.ftgroup> <CAKD1Yr3A6fzgTauLz+Yxe-xOLeDLZ5bzKBo-XyWU4i9LBSAM9Q@mail.gmail.com> <787AE7BB302AE849A7480A190F8B9330049122B6@OPEXCLILM23.corporate.adroot.infra.ftgroup>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Mon, 23 Feb 2015 19:49:07 +0900
Message-ID: <CAKD1Yr1c74gbnR51caf_WTKi7FFTbJP0KhwwXtabsvNhiE2Lgw@mail.gmail.com>
To: "<mohamed.boucadair@orange.com>" <mohamed.boucadair@orange.com>
Content-Type: multipart/alternative; boundary=001a114159b8f8823d050fbf27d4
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/rUNctpTEan1LDxikLhwGEd_tTSU>
Cc: V6 Ops List <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Feb 2015 10:49:29 -0000

On Mon, Feb 23, 2015 at 5:39 PM, <mohamed.boucadair@orange.com> wrote:

>  Operators who have deployed IPv6 report that running dual-stack over two
> PDP contexts is a very bad idea because it consumes 2x the network
> resources. Please don't recommend this unless you have evidence that this
> works well in production (not in testing).
>
>
>
> [Med] We are not recommending establishing systematically two PDP
> contexts. Please check the full recommendation provided below for your
> convenience.
>
>
>
>    C_REC#2:  The cellular host must comply with the behavior defined in
>
>              [TS.23060] [TS.23401] [TS.24008] for requesting a PDP-
>
>              Context type.  In particular, the cellular host must
>
>              request by default an IPv6 PDP-Context if the cellular host
>
>              is IPv6-only and request an IPv4v6 PDP-Context if the
>
>              cellular host is dual-stack or when the cellular host is
>
>              not aware of connectivity types requested by devices
>
>              connected to it (e.g., cellular host with LAN capabilities
>
>              as discussed in Section 3):
>
>
>
>              *  If the requested IPv4v6 PDP-Context is not supported by
>
>                 the network, but IPv4 and IPv6 PDP types are allowed,
>
>                 then the cellular host will be configured with an IPv4
>
>                 address or an IPv6 prefix by the network.  It must
>
>                 initiate another PDP-Context activation in addition to
>
>                 the one already activated for a given APN (Access Point
>
>                 Name).  The purpose of initiating a second PDP-Context
>
>                 is to achieve dual- stack connectivity by means of two
>
>                 PDP-Contexts.
>

How are you "not recommending" this behaviour, if the text says that the
device "must initiate another PDP-Context activation"?


>              *  If the subscription data or network configuration allows
>
>                 only one IP address family (IPv4 or IPv6), the cellular
>
>                 host must not request a second PDP-Context to the same
>
>                 APN for the other IP address family.
>
>
>
>              The text above focuses on the specification part which
>
>              explains the behavior for requesting IPv6-related PDP-
>
>              Context(s).  Understanding this behavior is important to
>
>              avoid having broken IPv6 implementations in cellular
>
>              devices.
>

I find this last paragraph meaningless. What is it intended to convey?