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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Mon, 23 February 2015 16:45 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 CDFC21A1B92 for <v6ops@ietfa.amsl.com>; Mon, 23 Feb 2015 08:45:49 -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 YJI1GyDRAIWx for <v6ops@ietfa.amsl.com>; Mon, 23 Feb 2015 08:45:44 -0800 (PST)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7DC31A1B6E for <v6ops@ietf.org>; Mon, 23 Feb 2015 08:45:42 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1NGjeBX009715; Mon, 23 Feb 2015 17:45:40 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6FECD2036D0; Mon, 23 Feb 2015 17:46:51 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 62F992036CB; Mon, 23 Feb 2015 17:46:51 +0100 (CET)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1NGjcrR003928; Mon, 23 Feb 2015 17:45:40 +0100
Message-ID: <54EB5932.70807@gmail.com>
Date: Mon, 23 Feb 2015 17:45:38 +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: Ca By <cb.list6@gmail.com>
References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <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> <54EB5468.4060401@gmail.com> <CAD6AjGSxRQMGLKwxVMfHgYT7n1C38LM57+csSzPmnRSe=kXQHg@mail.gmail.com>
In-Reply-To: <CAD6AjGSxRQMGLKwxVMfHgYT7n1C38LM57+csSzPmnRSe=kXQHg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/4w_v5fqsJB4usMEglrDRJvnvYg0>
Cc: IPv6 Ops WG <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 16:45:50 -0000

Le 23/02/2015 17:33, Ca By a écrit :
>
>
> On Mon, Feb 23, 2015 at 8:25 AM, Alexandru Petrescu
> <alexandru.petrescu@gmail.com <mailto:alexandru.petrescu@gmail.com>> wrote:
>
>     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>
>         <mailto: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.
>
>
> I don't think the IETF is willing to recommend what you have described
> above.

I dont think IETF wants to recommend many things, I agree.

I dont think anybody says IPv4 does not exist either.

And I dont think anybody will refuse an offer of a publicly routable 
IPv6 address and an IPv4 address be it private.

I sense the lack of IPv4 address (even a private one) as lack of 
connectivity.

>     One would appreciate an IPv4 private address with IPv4IPv6-type rather
>     than an IPv6-only type.
>
>
>
> Not this "one".  But, you can run your network how you like.

:-) ok

You seem to favor IPv6-only PDP type, right?

You do agree that CLAT has some problems, including with IPv4-only 
devices behind a tethering smartphone, no?

>
>         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
>         <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.
>
>
> This advice you provide has not been deployed in production.

In some places many things can be tried prior to converging.  That's an 
enviable situation.

In other places there is less chance to try many things, one should be
best at the first trial.

Alex

>
> CB
>
>     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> <mailto:swmike@swm.pp.se
>         <mailto:swmike@swm.pp.se>>
>
>              ___________________________________________________
>              v6ops mailing list
>         v6ops@ietf.org <mailto:v6ops@ietf.org> <mailto:v6ops@ietf.org
>         <mailto:v6ops@ietf.org>>
>         https://www.ietf.org/mailman/____listinfo/v6ops
>         <https://www.ietf.org/mailman/__listinfo/v6ops>
>              <https://www.ietf.org/mailman/__listinfo/v6ops
>         <https://www.ietf.org/mailman/listinfo/v6ops>>
>
>
>
>
>         _________________________________________________
>         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 <mailto:v6ops@ietf.org>
>     https://www.ietf.org/mailman/__listinfo/v6ops
>     <https://www.ietf.org/mailman/listinfo/v6ops>
>
>