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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Mon, 23 February 2015 16:25 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 93FE41A1AAA for <v6ops@ietfa.amsl.com>; Mon, 23 Feb 2015 08:25:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level:
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, 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 b_gjCFK2Dvht for <v6ops@ietfa.amsl.com>; Mon, 23 Feb 2015 08:25:17 -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 86FC61A1B87 for <v6ops@ietf.org>; Mon, 23 Feb 2015 08:25:15 -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 t1NGPDIb026893 for <v6ops@ietf.org>; Mon, 23 Feb 2015 17:25:13 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0A189203647 for <v6ops@ietf.org>; Mon, 23 Feb 2015 17:26:25 +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 0265D203630 for <v6ops@ietf.org>; Mon, 23 Feb 2015 17:26:25 +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 t1NGPCta007462 for <v6ops@ietf.org>; Mon, 23 Feb 2015 17:25:13 +0100
Message-ID: <54EB5468.4060401@gmail.com>
Date: Mon, 23 Feb 2015 17:25:12 +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> <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> <CAKD1Yr1ZG_rOZLCXtOjeNwAHbKzcnuRzUhitznp-5J0RP4CV9w@mail.gmail.com> <alpine.DEB.2.02.1502231459150.4007@uplift.swm.pp.se> <CAKD1Yr1Zsy2PBGLLi6trssAkY6nX==5jQLyodnWz_+H1BmXaPA@mail.gmail.com> <alpine.DEB.2.02.1502231515290.4007@uplift.swm.pp.se> <CAKD1Yr0WNGQQ5rv=tShduSS1J+VuA+kTPomPJa9tznMyiGTffQ@mail.gmail.com> <alpine.DEB.2.02.1502231530230.4007@uplift.swm.pp.se> <CAKD1Yr0Yfw_XRthJEWE+mrgqt619grLJH0BjoVeioz1GZFKOvw@mail.gmail.com> <alpine.DEB.2.02.1502231601490.4007@uplift.swm.pp.se> <CAD6AjGT1MkAPAPWe4rz1v3R60zcAX+jF02LTFSmkWt5q9qyEYQ@mail.gmail.com>
In-Reply-To: <CAD6AjGT1MkAPAPWe4rz1v3R60zcAX+jF02LTFSmkWt5q9qyEYQ@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/-E1zsWME3cBn4zJB4Vk46NEqk_c>
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 16:25:19 -0000

Le 23/02/2015 16:57, Ca By a écrit :
>
>
> On Mon, Feb 23, 2015 at 7:04 AM, Mikael Abrahamsson <swmike@swm.pp.se
> <mailto:swmike@swm.pp.se>> wrote:
>
>     On Mon, 23 Feb 2015, Lorenzo Colitti wrote:
>
>         I stand by my earlier questions. Do we have evidence that people
>         do this in production? It's not just the money - Dual-PDP is
>         either a 100% increase or a 50% increase in state and signaling
>         load over single-PDP. It also has worse fate-sharing properties
>         (e.g., IPv4 can fail but IPv6 can be working, and vice versa).
>         Is that something we want to recommend?
>
>         I get it that if you're an operator, the ideal situation is that
>         you have a
>         knob to control every possible aspect of device behaviour, even
>         if you
>         never use it. But forget about that for a moment. Remember, this
>         group is
>         about providing *operational guidance*. Is this really something
>         you would
>         recommend operationally? If so, why?
>
>
>     My opinion is the following:
>
>     We should recommend to run IPv4v6 whereever possible to operators,
>     for the reasons you provide.
>
>
> i don't see how we, v6ops,  can recommend operators deploy ipv4
> addresses that are not available.

Cameron - these addresses _are_ available, they're NATted anyways.

I know the IPv4 exhaustion problem, but it does not apply here: that
problem is a _publicly_ routable IPv4 address problem, not a private
routable address problem. One can have larger than 2^32 networks
entirely on IPv4 with multiple NATs and/or traffic engineering.

One would appreciate an IPv4 private address with IPv4IPv6-type rather
than an IPv6-only type.

> Should we include an appendix listing ipv4 brokers they can contact?

YEs, it is good to have such a list in one place. Do they do this
automatically or does one have to fill in forms?

> Oh, and don't forget the v6ops is also publishing this
>
> https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-roaming-analysis-07
>
> Quoting:
>
> "In the network attachment stage, PDP/PDN type IPv4v6 is the major
>
>     concern to the visited pre-Release 9 SGSN. 3GPP didn't specify PDP/
>     PDN type IPv4v6 in the earlier releases.  That PDP/PDN type is
>     supported in new-built EPS network, but isn't supported well in the
>     third generation network."

So the network should be updated to support IPv4IPv6 type.

Alex

>
>
> CB
>
>     We should recommend device manufacturers to follow the 3GPP
>     standards and set up a second PDP context when it receives CC#52.
>
>
>     --
>     Mikael Abrahamsson    email: swmike@swm.pp.se <mailto:swmike@swm.pp.se>
>
>     _________________________________________________
>     v6ops mailing list
>     v6ops@ietf.org <mailto:v6ops@ietf.org>
>     https://www.ietf.org/mailman/__listinfo/v6ops
>     <https://www.ietf.org/mailman/listinfo/v6ops>
>
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>