Re: [Detnet] [5gangip] Network Slicing - a suggestion that we meet to discuss in Seoul

Jon Crowcroft <jon.crowcroft@cl.cam.ac.uk> Thu, 03 November 2016 07:09 UTC

Return-Path: <crowcroft@gmail.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E78129467; Thu, 3 Nov 2016 00:09:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 URTld6Fsir6z; Thu, 3 Nov 2016 00:09:36 -0700 (PDT)
Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 52F25129423; Thu, 3 Nov 2016 00:09:36 -0700 (PDT)
Received: by mail-lf0-x235.google.com with SMTP id b81so30366345lfe.1; Thu, 03 Nov 2016 00:09:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=qrpjJu38LiOpd5cnMj+0HO41GwH2JLO7Ja0WyWD5PTQ=; b=FdUxl21L4VyNky92QFIJknUu29C0uj6sUryLoNWUmuPnxd8JtPxk5YHrAAixvhXf2K FMWIpEGQ2SpqELKBejI1YAnT/neDkrWSQMMu2fJlYv+41Im4XMHjTUZl9HZQThxGgCBp sFGj8GI9xS/VzoBagYRpJ834jPVFj5yFGiiBJyZiBmtkJ8z1HvXn74UFnubMrGe7RQym LPK/d7OVi4Wj92PCzR3TNg+UpH5x93/x/5LB3Pz0+ms6CzuvSKVYi/kz6Ckm4M7/j6xy xtgLF06Gpar5V947OBPBkCqVx/l5paShRd9hXxaxSZm9mEtMtpgjqUOPs5245NUf2sez DgGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=qrpjJu38LiOpd5cnMj+0HO41GwH2JLO7Ja0WyWD5PTQ=; b=fUwweHZx2EXjtxWuplqdyACMw9xyAV5ZKOZD7e+L67Y//HGeEchGnmBoDpa8Pzo6p0 KP3/w12ligkk+ttUPDJRzFvk5d9yhNGuBAN94uvLmy1JG2Hb9vT1hSmqfdX7Wlu2Oie8 6QA3rzw05VWv9BUja4Js0MvrSI10L2gv16T6AxOL64Qmkqdm0Mw3OhKLdlgUQPwLuHjH eW+5rHjSVjWmcLTfM7F0Bh6ddU4fZI1TelDj5WpsBwHzy9kTybVCaOPbiOKTSXbMNAz0 iJ0/KWB0NONmP0XBUgUReHZR+rseq/mnoW6/IYauLGub/QodshoFWTlncjMIZBbbYrDN wa1w==
X-Gm-Message-State: ABUngvc8HS3GHuJEMtpRbV7yiJ0DEaKytiWfkpuzlMHkOoIRX6T7hIfngsaxvFqr3Edz+vXJHvZo9fLQ/R2DMg==
X-Received: by 10.25.20.199 with SMTP id 68mr4518833lfu.111.1478156974261; Thu, 03 Nov 2016 00:09:34 -0700 (PDT)
MIME-Version: 1.0
Sender: crowcroft@gmail.com
Received: by 10.25.24.93 with HTTP; Thu, 3 Nov 2016 00:09:33 -0700 (PDT)
In-Reply-To: <65c50148-ad29-db00-a829-f0e34fd7b50f@gmail.com>
References: <65c50148-ad29-db00-a829-f0e34fd7b50f@gmail.com>
From: Jon Crowcroft <jon.crowcroft@cl.cam.ac.uk>
Date: Thu, 03 Nov 2016 07:09:33 +0000
X-Google-Sender-Auth: FmcbMmJc_MFiL4oY6Aq2PMjE2Wg
Message-ID: <CAEeTejLpCA1qkoeZoV9VbBaKwsyu4bSqZUZUvVK34oE7Zm=7Sg@mail.gmail.com>
To: Stewart Bryant <stewart.bryant@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/vop9CHD0QQlMRJKB5vJmGa2iWj8>
Cc: "Dongjie (Jimmy)" <jie.dong@huawei.com>, Mach Chen <mach.chen@huawei.com>, draft-xuan-dmm-multicast-mobility-slicing@tools.ietf.org, draft-ietf-teas-actn-framework@tools.ietf.org, nfvrg@irtf.org, draft-galis-anima-autonomic-slice-networking@tools.ietf.org, 5gangip@ietf.org, draft-vonhugo-5gangip-ip-issues@tools.ietf.org, detnet@ietf.org
Subject: Re: [Detnet] [5gangip] Network Slicing - a suggestion that we meet to discuss in Seoul
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Nov 2016 07:09:38 -0000

This stuff is routine in multi-tennant data centers where you want to
isolate tennants both at the VM level and at the VPN level, so you
need to dice and slice everything from app, os, nic, switches and
links....
lots of hypervisors&NICs support this at scale in that context - it
needs documenting how its managed, the importing into the ietf/5g
world....

On Tue, Nov 1, 2016 at 3:14 PM, Stewart Bryant <stewart.bryant@gmail.com> wrote:
>
> Hi,
>
> We were trying to pull together a problem statement for network slicing
> in a 5G context to understand how well the current IETF protocols address
> this problem, what their short comings might be, and what IETF work is
> necessary to have a deployable protocol suite to address this need.
>
> We have set down our first thoughts in
> https://tools.ietf.org/html/draft-dong-network-slicing-problem-statement-00
>
> We find that there are a number of groups doing similar work throughout the
> IETF.
>
> The following comprehensive draft was directed at the ANIMA WG
> https://datatracker.ietf.org/doc/draft-galis-anima-autonomic-slice-networking/
>
> https://tools.ietf.org/html/draft-vonhugo-5gangip-ip-issues-00
> is a detailed discussion the position of network slicing in a contest of
> next
> generation networks
>
> https://tools.ietf.org/html/draft-xuan-dmm-multicast-mobility-slicing-00
> looks at multicasting in a sliced context
>
> and
>
> https://tools.ietf.org/html/draft-ietf-teas-actn-framework-01
> looks at slicing in a context of traffic engineering.
>
> Our thoughts are that network slicing spans a number of deployment
> scenarios, and has a number of diverse applications, ranging from
> fragile applications, through to providing enhanced security and
> availability.
>
> Elements of the problem and the resultant solution have a close affinity
> to DETNET. There is clearly an affinity with VPN technologies, although
> none of the existing VPNs provide the degree of isolation that we think
> is required.
>
> We note that there seems to be no natural home for all of the aspects
> of this problem.
>
> It therefore seems that if would be a good idea for those interested
> in this problem to get together at some point during IETF to swap notes
> and share our views on the problem space and how to move forward
> with addressing it.
>
> Is there any interest in meeting up to discuss this in Seoul?
>
> Best regards
>
> Stewart/Mach/Jie
>
>
>
>
> _______________________________________________
> 5gangip mailing list
> 5gangip@ietf.org
> https://www.ietf.org/mailman/listinfo/5gangip