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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Mon, 23 February 2015 14:57 UTC

Return-Path: <alexandru.petrescu@gmail.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 0C71F1A0193 for <v6ops@ietfa.amsl.com>; Mon, 23 Feb 2015 06:57:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.983
X-Spam-Level:
X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 qvx_EQoedbN1 for <v6ops@ietfa.amsl.com>; Mon, 23 Feb 2015 06:57:13 -0800 (PST)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DE421A1ADD for <v6ops@ietf.org>; Mon, 23 Feb 2015 06:57:13 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1NEvBxR022341 for <v6ops@ietf.org>; Mon, 23 Feb 2015 15:57:11 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4C2E1203547 for <v6ops@ietf.org>; Mon, 23 Feb 2015 15:58:22 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4449520322D for <v6ops@ietf.org>; Mon, 23 Feb 2015 15:58:22 +0100 (CET)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1NEvALO018598 for <v6ops@ietf.org>; Mon, 23 Feb 2015 15:57:11 +0100
Message-ID: <54EB3FC5.4000904@gmail.com>
Date: Mon, 23 Feb 2015 15:57:09 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: v6ops@ietf.org
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> <787AE7BB302AE849A7480A190F8B9330049124F0@OPEXCLILM23.corporate.adroot.infra.ftgroup> <D11092F8.1AD6E%dave.michaud@rci.rogers.com>
In-Reply-To: <D11092F8.1AD6E%dave.michaud@rci.rogers.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/N7rEmkLcQTbXGMjFP3VqnjazujI>
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 14:57:16 -0000

Le 23/02/2015 14:25, Dave Michaud a écrit :
> To further clarify the comment below, this is not a recommendation but
> it is the expected behaviour as per the 3GPP spec.
>
> Upon receiving a request for a dual-stack PDP, the network operator can
> return one of the following cause codes (there are a lot more options
> but these are the relevant ones for discussion):

And what is the Cause code number for "PDP Type IPv4IPv6 allowed"?

If there is no such Cause code then it would make sense to add it.

Alex

>
> Cause code 50: PDP Type IPv4 only allowed
> Cause code 51: PDP Type IPv6 only allowed
> Cause code 52: Single address bearers only allowed
>
> In the first 2 causes (CC50 & CC51), the UE is to accept the PDP type
> selected by the network (IPv4 or IPv6) and not proceed further. Cause
> code 52 is the mean by which the network signals that it will allow two
> distincts PDP of different address type. In that case only is the UE
> suppose to go back and request a second PDP with the alternate type not
> offered by the network at the same time cause code 52 was returned.
>
> "If the requested IPv4v6 PDP-Context is not supported by
>
> the network, *but IPv4 and IPv6 PDP types are allowed**…*” —> This is
> signalled with cause code 52.
>
>
>
> *
> *
> *Dave Michaud*
> Sr. Architect Mobility – Access Networks & IP Network Services
> Network Technology | Rogers Communications
> dave.michaud@rci.rogers.com <mailto:dave.michaud@rci.rogers.com> | tel:
> +1 647.747.9442 | mobile: +1 416.219.5531
>
>
> From: "mohamed.boucadair@orange.com
> <mailto:mohamed.boucadair@orange.com>" <mohamed.boucadair@orange.com
> <mailto:mohamed.boucadair@orange.com>>
> Date: Monday, February 23, 2015 at 07:10
> To: Lorenzo Colitti <lorenzo@google.com <mailto:lorenzo@google.com>>
> Cc: IPv6 WG <v6ops@ietf.org <mailto:v6ops@ietf.org>>
> Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
>
> 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).
>
>
>
>
>
> ------------------------------------------------------------------------
> This communication is confidential. We only send and receive email on
> the basis of the terms set out at www.rogers.com/web/content/emailnotice
> <http://www.rogers.com/web/content/emailnotice>
>
>
>
> Ce message est confidentiel. Notre transmission et réception de
> courriels se fait strictement suivant les modalités énoncées dans l’avis
> publié à www.rogers.com/aviscourriel <http://www.rogers.com/aviscourriel >
> ------------------------------------------------------------------------
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>