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

<mohamed.boucadair@orange.com> Mon, 23 February 2015 12:10 UTC

Return-Path: <mohamed.boucadair@orange.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 5C3181A1A6A for <v6ops@ietfa.amsl.com>; Mon, 23 Feb 2015 04:10:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
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 eejOnO6L3KZI for <v6ops@ietfa.amsl.com>; Mon, 23 Feb 2015 04:10:21 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149741A1A65 for <v6ops@ietf.org>; Mon, 23 Feb 2015 04:10:21 -0800 (PST)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 588C21B82DC; Mon, 23 Feb 2015 13:10:19 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id ED1D4180104; Mon, 23 Feb 2015 13:10:18 +0100 (CET)
Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Mon, 23 Feb 2015 13:10:18 +0100
From: mohamed.boucadair@orange.com
To: Lorenzo Colitti <lorenzo@google.com>
Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
Thread-Index: AQHQT1Zm5Ax3nzpG/0OJ6Y4TQVbtUJz+IFhw
Date: Mon, 23 Feb 2015 12:10:18 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330049124F0@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> <CAKD1Yr1c74gbnR51caf_WTKi7FFTbJP0KhwwXtabsvNhiE2Lgw@mail.gmail.com>
In-Reply-To: <CAKD1Yr1c74gbnR51caf_WTKi7FFTbJP0KhwwXtabsvNhiE2Lgw@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330049124F0OPEXCLILM23corp_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.23.103920
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/xr3NrtroDBRJkRypGWEAfkrqpfM>
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 12:10:24 -0000

Re-,

Please see inline.

Cheers,
Med

De : Lorenzo Colitti [mailto:lorenzo@google.com]
Envoyé : lundi 23 février 2015 11:49
À : BOUCADAIR Mohamed IMT/OLN
Cc : Mikael Abrahamsson; V6 Ops List
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

On Mon, Feb 23, 2015 at 5:39 PM, <mohamed.boucadair@orange.com<mailto: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"?

[Med] It seems you skipped “systematically” in my answer ;-). So, I confirm “we are not recommending establishing systematically two PDP contexts”. The default behavior is to ask for a IPv4v6 PDP-Context, but (1) if the IPv4v6 PDP-Context is not supported, and (2) if IPv4 and IPv6 PDP types are allowed, two PDP contexts can be requested. The network is free to accept those or not. As you can see there are “if”s in this behavior. So to be accurate, this text does not recommend requesting two separate PDP contexts as default behavior, but it does not forbid it either.

             *  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?

[Med] FWIW, the last paragraph was added as per a comment received from the mailing list: https://www.ietf.org/mail-archive/web/v6ops/current/msg14716.html. The point is that the set of cited specifications contains more details about how PDP contexts are to be handled compared to what is described in here (that is IPv6-sepcific).