Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services

Uma Chunduri <umac.ietf@gmail.com> Thu, 09 April 2020 01:39 UTC

Return-Path: <umac.ietf@gmail.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8353A1D2C for <architecture-discuss@ietfa.amsl.com>; Wed, 8 Apr 2020 18:39:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 RyuBTCsJEMJp for <architecture-discuss@ietfa.amsl.com>; Wed, 8 Apr 2020 18:39:38 -0700 (PDT)
Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (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 6914C3A1D29 for <architecture-discuss@ietf.org>; Wed, 8 Apr 2020 18:39:38 -0700 (PDT)
Received: by mail-ua1-x929.google.com with SMTP id v24so3411693uak.0 for <architecture-discuss@ietf.org>; Wed, 08 Apr 2020 18:39:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rndXhXGo0fcacPARBfxG6pmB96xuzxE3P2MVrZReios=; b=VNGXoN+qLeosXSdm6N102Jx5BXXDuGZmEMI25O/FXzW+QAx+DKiykY5OuJncbMdEVF oL0+jSovevvmomjq4tBVNWj+TMAaCYmM0w+ya4x/ty8gEnQsojdTdvlWKATgFjzmgtPp VhAnVbZo4y+HhSBQq+haEJ5TVWO/P3Soleqi8S6YXtCI21kHOTXMNpQj21u49UT8tsTr efIzORDTkkypXuk6n+78McXJSrwZRSBarrAl9DTkSDc8nKlkyH5mMIwpQkGkpMJRBg1n jzx581B++RyMNkC3ZQ0rLCwOlqUq15VbWxYZ+JPsNABU3++Pu2vF6MdBiLwLZlLOipcZ xNxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rndXhXGo0fcacPARBfxG6pmB96xuzxE3P2MVrZReios=; b=e3WbRvD1tFtooRm3EI878hBYChcYhLnzaP1E3hJDcw2NrPe7lT04Z1DL8KUxlrXxN3 ihHFXUpOTnKECFv+JnVt7Shj9EracvcgLAc1eqx738zaBH/MpEV0F2EvYnPxLfDXHq8o T28tLTj+kkiR4au7dUKhvZ7ME13AwAlXfjjohJc/rXOA0yTr7RfHuNnRsAX5ALh3tcVx AYUTtUACKRYBYhn3J4DFuj0qh1+c2OnWvSnltwUihsSjuHC1/rl8c2QW8Ej0fwEAtSCP kpzHtvJqFpMKhkcA4SoVugJGM9F7KSmGdtwSg0XBknuIBMOKVerRWD5C4Kfc3esuA61Y LnwA==
X-Gm-Message-State: AGi0PuaShhDOL96FsdOuAohwMo/yiIJVfqgkvmXOq2HcdkU2+6hbBcXd TQQVahLyxw30+yDZyirKgUwjQ7gjh4biWBpFDR5mDnmB
X-Google-Smtp-Source: APiQypKvC1tFl4vVo1oeyS8XUc45EQ6WaFIPOMeP/bayvsL4ZhpluedUEfPF2cHSpxe1hYY9CXj9C8fHnW54i5rg8uc=
X-Received: by 2002:ab0:73cd:: with SMTP id m13mr917897uaq.22.1586396377258; Wed, 08 Apr 2020 18:39:37 -0700 (PDT)
MIME-Version: 1.0
References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <3F26D0A8-28DE-4F35-B4B9-2346A8AED46F@gmail.com> <AC46F652851E6AB5AB3D9B8C@PSB> <20200408205338.GM28965@faui48f.informatik.uni-erlangen.de>
In-Reply-To: <20200408205338.GM28965@faui48f.informatik.uni-erlangen.de>
From: Uma Chunduri <umac.ietf@gmail.com>
Date: Wed, 08 Apr 2020 18:39:41 -0700
Message-ID: <CAF18ct7vvewOKWEdZ5tuNkpB65tttVVnPUTWVzPTw_orkGhBDQ@mail.gmail.com>
To: Toerless Eckert <tte@cs.fau.de>
Cc: John C Klensin <john-ietf@jck.com>, architecture-discuss@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008a1ed105a2d1b075"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/RTus8hsDlaaKJPSsBqanyTRL75k>
Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Apr 2020 01:39:40 -0000

 Hi Toerless,

Your observations are right, of course
Quick replies in-line [Uma]:

On Wed, Apr 8, 2020 at 1:54 PM Toerless Eckert <tte@cs.fau.de> wrote:

> John,


> I think 3GPP 3/4/5/6G is not a fitting example to apply

the IP-over-foo approach.


> 4G/5G "core" networks effectively are overlays on top of of some

typically IP based transport network. Today the overlay nodes are mostly

software in edge-data-centers/pops. So its more naturally an

overlay.



[Uma]: Right. But those overlays served well and all IP/MPLS transformation
started there 10 years ago (from LTE days). It's only 2 bearers effectively
till now.  And those were simply not enough for some of the critical
services envisioned in 5G networks beyond eMBB (so called  "slice"). Hence
you will continue to see some of the efforts in this thread as in the
title  of this thread (while I know some of the big operators  which
support that I am not plugged in that effort).


> There is some liaison process whereby IETF technologies are pitching

their benefits to 3GPP if used an an underlay (i reall having

heard about this for SRv6 or LISP). Yet, 3GPP seems to prefer not

to really change anything fundamental in their overlay architecture

from what i've been told (only tangentially watching this).

"Only simple, minimal layering integration is good integration".



[Uma]: Lot of discussions couple of years ago in various side meetings. But
at the end those were not so fruitful.  Partly because there was a
misguided effort to remove their heavily deployed overlay.  Obviously,
collapsing underlay and overlay won't help. LISP is different and it can
potentially solve the control plane signaling and other issues in 3GPP
domain but it's not that backward compatible (yet). But I am sure, Dino and
other might be working in future releases ..


The more fundamental problem is that the mobile services in most

service providers are where the money is coming from, so now

they want to re-design the hardware underlay in their name, aka: the actual

physical network infrastructure besides DCs and radio towers.

And i think 3GPP has no clue what to do there exactly. But i

am sure that something strange will evolve.


[Uma]:  Yes; we all heard E2E slicing at some point in last few years?
There is a lot in that E2E including L2 and IP/MPLS. You can get only so
far moving the edge. Radio (with NR) is dis-aggregated  and  it doesn't
help even for small sub-set of use cases, which can be solved by
moving your DCs/Edge closure (cost, complexity and security issues).

But the bottom line is underlay (IETF) needs to evolve independently of
5G/B5G (at best this is one use case), given the earlier futile
discussions/efforts as you mentioned above. This would benefit vast number
of use cases with new media, non-eMBB slices and industrial internet
seeking beyond-best-effort which can co-exist along with BE. While I am not
claiming I know fully, but yes, some of these aspects could belong rightly
in this forum perhaps.


Cheers!
--
Uma C.





>