Re: [Ideas] [5gangip] Comments to draft-vonhugo-5gangip-ip-issues-00

Ca By <cb.list6@gmail.com> Wed, 21 September 2016 17:56 UTC

Return-Path: <cb.list6@gmail.com>
X-Original-To: ideas@ietfa.amsl.com
Delivered-To: ideas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662EE12BB9F; Wed, 21 Sep 2016 10:56:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 XwWZHb0YUOYP; Wed, 21 Sep 2016 10:56:12 -0700 (PDT)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 22DBA12BB9C; Wed, 21 Sep 2016 10:56:11 -0700 (PDT)
Received: by mail-wm0-x22c.google.com with SMTP id b130so105029293wmc.0; Wed, 21 Sep 2016 10:56:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t2xO5cIK3jLcgZ4cLWIn6qNPEBy/8mdPmZaBgS53moQ=; b=k2cxD9ITN9htw88cBM7owykmyUWtP0NTSvHQI1nMo4ooRUPsn9cfUX8heG/v3SznAn w4lujoMolUFPEwtzgPBGC2QTqfsKBwmr45bw/t7NAUeE6qE1tSd1qK2xqtSuuBj2hVgt V7V01vdtj8KFV4S4GpVS+qwIZhscOPR3TYJGSXzPxBUi4Yg6QTNlssqmwmA4ra03GV4k GXX7ch1+b4X4e1Mbz9biSH6e2FCPOJW+X2JOx5ZELbR5oMqqD1e95XkaTvsP98HKHhhd C4TrkcH27Em1XEciVfsRt5AmKwdXrW6Al0EOIkKyPO1aPb+mfgBB1wk/oTvHduqJlawj jMnw==
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; bh=t2xO5cIK3jLcgZ4cLWIn6qNPEBy/8mdPmZaBgS53moQ=; b=IvA1HUGJyZ88niHj0lhTAfEkHL2+PwOghAbmZkriUE3Sg3bDy+3W2ELJ6iHKp9ocKW 5gHePdTBp13ZUo1M1HbX3NVnhxKG2uMHB5RG9H5Gdn30A+4AhckbrPpX6yifNtoAs++T CIuvJOSeAC/+esSOa5K1pFhKLy+4gQf/Cw/4EOZ6wO/0YSqkXTFNcZ7WkeoaG5bKkg85 3fCBx0G0PJNTAJpF7nmpjvLepXx19+kTdVRKWG+j4a394ZhaVwEKQ2LUYOIkRp9H7egt 0til2GCWJx+zTMJ2aOXzdHrCf1XdzpJ/Xpji4cLDAPLYyAioENmKy4s1uahaR1nvjpbz t0ZQ==
X-Gm-Message-State: AE9vXwMWEO7NPjK8WCVlrrjxeonulfIOYNl1VfrW1DA+EvlEHr0nVcF5W0RM/Y+30N2+1+OUuwfjdLbUwYb3aw==
X-Received: by 10.28.66.6 with SMTP id p6mr4151667wma.59.1474480569637; Wed, 21 Sep 2016 10:56:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.175.15 with HTTP; Wed, 21 Sep 2016 10:56:09 -0700 (PDT)
In-Reply-To: <BB0E6438-E1F4-4D46-AA71-BC5EAE009433@gmail.com>
References: <AA6C2C69-3B95-4F14-B301-2B7DB83D3373@gmail.com> <CAC8QAcca1fx-Z8b-Q_Kdv9_ETgjov9RsPt+CeDN5wrC=5WoTaw@mail.gmail.com> <29FC5745-22E5-4E0E-A918-822BD30DE610@gmail.com> <7cc516e0-b966-5ed0-55ed-f6e31ec90753@htt-consult.com> <CAD6AjGQqq2Y7a7GkRyxJbaQU+1D1+BNqQjhxDudr=rppvjzKOQ@mail.gmail.com> <BB0E6438-E1F4-4D46-AA71-BC5EAE009433@gmail.com>
From: Ca By <cb.list6@gmail.com>
Date: Wed, 21 Sep 2016 10:56:09 -0700
Message-ID: <CAD6AjGSF80EMy4fDv8CSGmVMXN2+j+V=q-o8RCVos_Lzx1RiJQ@mail.gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
Content-Type: multipart/alternative; boundary=94eb2c072bb694e3ce053d084224
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/U4N0AF7PrTK-WjyGoXg7EKdjrJw>
X-Mailman-Approved-At: Wed, 21 Sep 2016 11:07:15 -0700
Cc: ideas@ietf.org, AshwoodsmithPeter <Peter.AshwoodSmith@huawei.com>, Tom Herbert <tom@herbertland.com>, Robert Moskowitz <rgm@htt-consult.com>, Behcet Sarikaya <sarikaya@ieee.org>, "Dirk.von-Hugo@telekom.de" <Dirk.von-Hugo@telekom.de>, David Meyer <dmm@1-4-5.net>, 5gangip@ietf.org, Padma Pillay-Esnault <padma0528@gmail.com>, Richard Li <renwei.li@huawei.com>
Subject: Re: [Ideas] [5gangip] Comments to draft-vonhugo-5gangip-ip-issues-00
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <ideas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ideas>, <mailto:ideas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ideas/>
List-Post: <mailto:ideas@ietf.org>
List-Help: <mailto:ideas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ideas>, <mailto:ideas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Sep 2016 17:56:15 -0000

On Wed, Sep 21, 2016 at 10:34 AM, Dino Farinacci <farinacci@gmail.com>
wrote:

> I get afraid that folks take this list too seriously. This list is simply
> a place to air "crazy ideas". Hopefully, a crazy idea that has potential
> gets traction, but i have not seen that yet.  I see the same old stale
> ideas that have failed in other venues get recycled and respun here.  More
> tunnels and more NAT to solve a problem we don't have....
>
> But they are tools we have in our collective toolbox. Some tools don it
> work well for certain tasks.
>
> I think the evolution within 3GPP is that the mobility system (GTP) is
> getting smaller and smaller, more and more distributed, so relevant
> innovation flows over the top, e2e gets restored....... If i am using
> netflix today on Wifi, and walk out the door and switch to LTE ... there is
> mobility there at the Netflix side....it just works ...  This is a problem
> solved at the application layer, we do not need complicated network layer
> things trying to insert themselves.
>
>
> You are making a good point.
>
> But it comes down to where you solve problems. And if you do it at the
> thin waist of the architecture then you solve mobility N times in each
> application.
>

i hear ya, but just like crypto / ipsec / TLS and, (gasp) multicast, the
thin waist has proven too thin. Which is fine, thin is thin.


>
> 5G is simply millimeter wave small cell spectrum and marketing.
>
>
> Well I think some people are trying also to make the 5G infra lower OpEx.
> Today the ~$50 cost to phone users can cover the infra costs. But what
> about when IoT devices which will be dirt cheap will need dirt cheap 5G
> service. Will that cover the high OpEx? Volume won't help the equation
> because greater scale will need to be dealt with.
>

This is sort of where i was going with reducing the existing mobility
system.  The cost comes from state and signalling of state, reducing the
mobility system reduces the state and allows us to scale.

10 years ago, all mobile devices for a larger mobile network terminated in
2 national locations in the USA.

Now, greater than 20 locations.

In 5 years, termination of the mobility system may be at the cell sites for
many cases (slices) while other slices require high level mobility
management (state, costs, ...)

These IoT devices, just like my phone streaming Netflix, quasi-statelessly
connects to the cloud.  Communication sessions are designed to be
ephemeral, and thus take on some greater robustness properties.


>
> Dino
>