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

Do Truong Xuan <thespring1989@gmail.com> Thu, 03 November 2016 07:37 UTC

Return-Path: <thespring1989@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 02959129529; Thu, 3 Nov 2016 00:37:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.189
X-Spam-Level:
X-Spam-Status: No, score=-2.189 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 sUcgqhhNAJX6; Thu, 3 Nov 2016 00:37:13 -0700 (PDT)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 0C4D81294A7; Thu, 3 Nov 2016 00:37:13 -0700 (PDT)
Received: by mail-qk0-x22e.google.com with SMTP id n204so36542172qke.2; Thu, 03 Nov 2016 00:37:12 -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=89woh0epbLHyh0v5EsjN4XPXZliCz5y6DtUe8i1q9bk=; b=rlqUUoMW8CAuEFa+u7cT1QwFeC3Eehf2CiFBmt2iMI7z7U/Q3Q6aA3jN0saLwGAzea OqQJbf71b70TGolV1qri5dMH/sSfK6gc+2vhMZY6hVY6E+crcOVzBDUHzYa3KVxmSmJT WXQTPFnnyT00+1tBWQ9TfSyGmXIUJbOoBUw/cBhfhnZmgZuV1eNBBHGFbaGw9pGpV+2W YGHaoNOwjhmibidRfiP0XOsEQijWn0UaoH1hIKyyHUOyfjg7u4AfqbmX2zKcOBxHW+et vqMBuqpBEDgp+OetcCVRCvwD1H1ILvNM9dDy+NzhPDv83KM2hE4t27fBzk0cTYl496A/ G27g==
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=89woh0epbLHyh0v5EsjN4XPXZliCz5y6DtUe8i1q9bk=; b=BbmkuTqsGgB/QNld5/P078/NjxwdcYzyl3PVVqTqbDfpAvi+vx++ja+k4W1E+ohsIc B6rjNofo+8Fe0SR+aDw82ajXRhvBeQefl9INN4zYx/NPvnmQPGyXdcLMl0EkLKs2ClpF jmT/obJgYHZ7itq+U68u+zl2zRQ8vm67A8aeTjH/txlRYQMcMsKgIAOKJLrbYFnAY4G5 D3PWjte86VZc1IFXsxD23sD5nS7ysnAy1UrFf/G7uA9j+D3mA9CrY6GtYMG6M4s1lTdE Rb7Zlj/LKZetx8DjcaC2TQ3+iqbgydHG/4DhAKUGVV914zlKfrw16hMQChRBPtDTp2FT 0w2A==
X-Gm-Message-State: ABUngvc4DsDZj51ufSv4/RaI+bK5eGW9FmKFoquiKN9gqlKb/rsSDUqkL6duiFitrhgXiK3orMVtYQaNr/B7gg==
X-Received: by 10.55.142.130 with SMTP id q124mr6280374qkd.220.1478158632123; Thu, 03 Nov 2016 00:37:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.67.74 with HTTP; Thu, 3 Nov 2016 00:37:11 -0700 (PDT)
In-Reply-To: <6761290b-eac5-8241-eb7f-32683fe594a1@gmail.com>
References: <6761290b-eac5-8241-eb7f-32683fe594a1@gmail.com>
From: Do Truong Xuan <thespring1989@gmail.com>
Date: Thu, 03 Nov 2016 16:37:11 +0900
Message-ID: <CALnYAC5+9+WbNTM=OUhBZE0p_W3FA52ZgOc2gzCz-2YFZ1cXUg@mail.gmail.com>
To: Stewart Bryant <stewart.bryant@gmail.com>
Content-Type: multipart/alternative; boundary="94eb2c0882b63081d6054060a0b6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/iyh0pgvCjhAGj_bErjeCNXsi32I>
Cc: "Dongjie (Jimmy)" <jie.dong@huawei.com>, Mach Chen <mach.chen@huawei.com>, draft-ietf-teas-actn-framework@ietf.org, draft-galis-anima-autonomic-slice-networking@ietf.org, nfvrg@irtf.org, 5gangip@ietf.org, detnet@ietf.org, draft-vonhugo-5gangip-ip-issues@ietf.org, draft-xuan-dmm-multicast-mobility-slicing@ietf.org
Subject: Re: [Detnet] 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:37:16 -0000

Hi !

+1

In the next generation network, IETF protocols and functions could be
changed and managed in a different way.
Network slicing is not just normal virtual private network but with
different requirements (high availability, latency ..) and various
functions.
It's worthy describing this topic in IETF too.


Brs,

On Wed, Nov 2, 2016 at 12:21 AM, Stewart Bryant <stewart.bryant@gmail.com>
wrote:

>
> (Resent with correct draft alias)
>
> 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-probl
> em-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
>
>
>
>
>


-- 

*Truong-Xuan, Do*

PHD Candidate

DCN Lab, Soongsil University

(+82) 10 4473 6869

xuan@dcn.ssu.ac.kr