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

Toerless Eckert <tte@cs.fau.de> Fri, 10 April 2020 01:05 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 86FF43A184E for <architecture-discuss@ietfa.amsl.com>; Thu, 9 Apr 2020 18:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Level:
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 5V6h44dUURCK for <architecture-discuss@ietfa.amsl.com>; Thu, 9 Apr 2020 18:05:55 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51AC03A184D for <architecture-discuss@ietf.org>; Thu, 9 Apr 2020 18:05:55 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 31D9B548017; Fri, 10 Apr 2020 03:05:50 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 25C77440040; Fri, 10 Apr 2020 03:05:50 +0200 (CEST)
Date: Fri, 10 Apr 2020 03:05:50 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: Dino Farinacci <farinacci@gmail.com>, Tony Li <tony1athome@gmail.com>, architecture-discuss@ietf.org
Message-ID: <20200410010550.GL44502@faui48f.informatik.uni-erlangen.de>
References: <20200409215925.GA44502@faui48f.informatik.uni-erlangen.de> <4BB15D5F-735F-409D-B518-DD99A4428794@gmail.com> <20200409222341.GC44502@faui48f.informatik.uni-erlangen.de> <952F886C-1B20-4E80-9948-D5D7EFF3BAA6@gmail.com> <20200409231646.GF44502@faui48f.informatik.uni-erlangen.de> <1936E4A5-6E5A-41AA-BA7F-B9EBEEE170C7@gmail.com> <20200409234251.GG44502@faui48f.informatik.uni-erlangen.de> <6D5C324F-9078-4DC5-8B5D-D0D95EB6D1C7@gmail.com> <20200409235935.GH44502@faui48f.informatik.uni-erlangen.de> <f1ba0f10-5571-410c-8475-ed59ae05b5dc@Spark>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <f1ba0f10-5571-410c-8475-ed59ae05b5dc@Spark>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/bBLRUVUdWLTHKM5QzgonqalwXi0>
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: Fri, 10 Apr 2020 01:05:58 -0000

On Thu, Apr 09, 2020 at 05:21:29PM -0700, Jeff Tantsura wrote:
> Toerless,
> 
> You have been mentioning P4 in almost every email.
> P4 (and similar) is an abstraction on top of forwarding plane, if anything - it doesn???t enhance one.
>  The problem with such layers in an heterogeneous environment - almost always they end up being lowest common denominator, or variability inevitably kills them (OF ;-))

Sure. BUt remember example from prior mail in this thread,
the question is what to do with such a programming
language. E.g.: using it purely as a proof of feasiblity
of a proposed forwarding plane function. This is just
one example. Your argument that is often lowest common
denominator seems to very well support this option.
We already know it makes researchers happy. thats a second
example. Using it to write highest performance production
probably as you said not ideal for that. But initial
research might well get away with lower speed or lower scale code.

> At scale - In the chain NB(programmable logic you interact with)->magic(translation from high level to 0..1)->SB - SB(silicon) is fixed, magic is limited by amount of permutations, eventually NB that is exposed to you have to limit amount and variability of features to support more than 1 target.

Exactly. Thats another core important aspect to consider.

> So if I end up with: convoluted management plane (I have to program my forwarding plane directly, 1:1 relationship)  a handicapped feature set across different HW and at the end can't do anything else at line rate  besides moving IP packets from A to B??? I???d stick to BGP ;-)

I think you are taking apart a combination of options of your own design ;-)

Today, everybody can fairly easily build a virtual programmed
overlay network as long as he just uses routers that are
VM/container in DCs, and somehow doesn't have to care
about controlling QoS on the paths between them, but is
fine with controlling them indirectly. SD-WAN being one example
of such overlay networks. And there is IMHO a lot of
great innovation in it. Is the innovation inside the
network layer ? Who knows, its all proprietary. I'd guess there
is some.

So, how do i make a hardware router/switch based metro network
a possible target for such innovator ? Make it programmable.
And of course that comes with a lot of challenges. But it
wrt. management plane it could be similar to how a
SW-overlay network is deployed on DC: Totally separate to
what the actual SW on the VM/containers does. Aka: The
system to download some P4++ code into a network infra has
nothing to do with what protocols that P4++ code implements.

Cheers
    Toerless

> Cheers,
> Jeff

> On Apr 9, 2020, 4:59 PM -0700, Toerless Eckert <tte@cs.fau.de>, wrote:
> > On Thu, Apr 09, 2020 at 04:54:24PM -0700, Dino Farinacci wrote:
> > > > I would alredy be happy if we had a better overall system standard
> > > > to simply operationale path diversity. distributed MRT IGP
> > > > extensions was the only thing i rememer we did, and while
> > > > its cool, it doesn't offer lowest latency (shorted path
> > > > length compared to centralized diverse path calculation).
> > > > Hence also proposal from our side like PPR for easier
> > > > forwarding plane agnostic path engineering.
> > >
> > > Then why don???t you write a solutions draft that says ???use X, Y, and Z protocols that allows near-zero packet loss and probablisic delays???.
> >
> > There is always more drafts one could write than time. We
> > presented PPR drafts as a generic concept, its benefits and
> > maybe even specific details for disjoint paths is still
> > one some Todo list.
> >
> > > > The simple n-path diverse pathset calculation is easy to
> > > > use in any network, thats why its a good starting point
> > > > the more dynamic mechanisms you mention are still good
> > > > research topics IMHO. At least for quantitive evaluations.
> > >
> > > That???s right. So write a draft that starts out using IP. It will go a long way and you can test it sooner. ;-)
> >
> > I am not even sure that something that improves IPv4 value
> > equal to IPv6 would be welcome by part of the community ;-)
> >
> > But i think there are a lot more pieces to the puzzle
> > than path diversity, and those othre pieces would
> > require additional header info, and thats where we
> > run into 8200 and other issues.
> >
> > Cheers
> > Toerless
> >
> > _______________________________________________
> > Architecture-discuss mailing list
> > Architecture-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/architecture-discuss

-- 
---
tte@cs.fau.de