Re: [Teas] The definition of a Network Slice in draft-nsdt-teas-ietf-network-slice-definition

Young Lee <younglee.tx@gmail.com> Mon, 16 November 2020 13:38 UTC

Return-Path: <younglee.tx@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FE63A0FB3; Mon, 16 Nov 2020 05:38:19 -0800 (PST)
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 383XQYDvvxBd; Mon, 16 Nov 2020 05:38:17 -0800 (PST)
Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 8EA8E3A0DF3; Mon, 16 Nov 2020 05:38:17 -0800 (PST)
Received: by mail-ot1-x32d.google.com with SMTP id h16so11897845otq.9; Mon, 16 Nov 2020 05:38:17 -0800 (PST)
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=xEzpRfYvROMelCrb0ufrUIvtuu8QM0yLZky0urUIoxU=; b=eFmUzzGyssFgSjkYrol4FxWhvJdWq79y8o+dqHvLLSIAyMfaSSU5ti+1uNydJ9Y8L+ LCgJPqZdAzCpfhB2lbN42lUXu+BQFondlpJQIdtCTbeeQNNmfM/4rApT9Ublvf/z9+dg OQjE2gp67r/j7Y985PRCQtSyXaOErLKU9LvUkiSeCFydHev1IqltsKW7aX4AkhmSNQ/U 41yPRXfWEx1eMZeby4FX0h1GUHGWjvoABZMq59+K1zmtS1ylogf5Yyb5KjzJhYOxjqez 4aN5L/rxWgpYsZFcsKr6U7LIOupU5lxMWaEJ3VvUar5Ta9H3vpn8Ag56yKfwMP+7kn8T /K1Q==
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=xEzpRfYvROMelCrb0ufrUIvtuu8QM0yLZky0urUIoxU=; b=UWtS0VB4rlckYKWUxoi1DwihcgVcBYUhcziBoF+CkiJnfsNSwEaTin+J2KxctbPIF0 +0DLVlbmdw3bvpb00nrc0LunUenY8VqSThuIasFpyp5UN03SdaIviRqtKCv3RaxHc9H6 4bntOswezchb+2g26zQECqqmwMK1GcxlZVCZlgzcEiAvA9Eq6JA39T5Vy1chiWAs1g4k qawBsy/xQcZOdCpFG/KOp8B/S0erLHHvDjgxgEKHr1wfe63BgBgq9vvyAd+PRIwKIsH1 aFn1NqEghl70rsEzu81wQTTFTnOBLl8x3hXHZHl/2T8rnXQgi7FL0j8m4x13o3yTY0G5 9PSw==
X-Gm-Message-State: AOAM5338JXpBvnD1WD22XEkX1jXpOKg9gFEDtLWO/nIqQ4C0h1bYSm9N wjREpCxZjEnZhxswk9ePBsVeuC7iXHeZnQHfxJ0=
X-Google-Smtp-Source: ABdhPJw8yjG0S3ZzB/ZsPosRhxWt+YI2D4I1EMB26VXROxbaDCGeHeRyoJKuBxFTvUbTT9LeaaNLdOfkB/iwcF5no7s=
X-Received: by 2002:a9d:6c99:: with SMTP id c25mr11241279otr.327.1605533896738; Mon, 16 Nov 2020 05:38:16 -0800 (PST)
MIME-Version: 1.0
References: <008201d6bacb$26b80590$742810b0$@olddog.co.uk> <CC4564AA-ECD9-4E52-8508-FB87139C6F21@piuha.net> <016201d6bb9a$c64cd4d0$52e67e70$@olddog.co.uk> <18004_1605514109_5FB2337D_18004_262_1_787AE7BB302AE849A7480A190F8B93303157A50E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <HE1PR07MB4156A0AACC1C378DE897F3A0F0E30@HE1PR07MB4156.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR07MB4156A0AACC1C378DE897F3A0F0E30@HE1PR07MB4156.eurprd07.prod.outlook.com>
From: Young Lee <younglee.tx@gmail.com>
Date: Mon, 16 Nov 2020 22:38:05 +0900
Message-ID: <CAGHSPWNLt=DsQzaazNMMSDYYLX=QRBLhWg-ww1t+iVoqDfmrCA@mail.gmail.com>
To: Daniele Ceccarelli <daniele.ceccarelli=40ericsson.com@dmarc.ietf.org>
Cc: mohamed.boucadair@orange.com, adrian@olddog.co.uk, Jari Arkko <jari.arkko@piuha.net>, "draft-nsdt-teas-ietf-network-slice-definition@ietf.org" <draft-nsdt-teas-ietf-network-slice-definition@ietf.org>, "teas@ietf.org" <teas@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000970c4505b4397d51"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/3P-r3i0UjzUVpaZDCVruUUpV_74>
Subject: Re: [Teas] The definition of a Network Slice in draft-nsdt-teas-ietf-network-slice-definition
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Nov 2020 13:38:19 -0000

I tend to agree with Daniele. We should focus on connectivity slice in IETF
at least for now. Then other types of slices that are being defined and
modeled by other SDOs (such as RAN slice and Core Network slice) should be
first evaluated to see if there would be any lack. Only then we would know
if and what IETF can fill the gap.

Perhaps this is another way of saying what Adrian initially stated.

Best regards,
Young



2020년 11월 16일 (월) 오후 9:37, Daniele Ceccarelli <daniele.ceccarelli=
40ericsson.com@dmarc.ietf.org>님이 작성:

> Hi Med,
>
> This seems to be re-opening Pandora's box.
> My understanding was that the IETF network slice was the connectivity
> component of an E2E slice.
> If we're now thinking of the connectivity part of the IETF network slice
> it means we're "elevating" the IETF network slice to compete with other
> definitions of E2E network slices.
>
> I would agree with Jari on the fact that it would be more efficient to
> focus on what we're good at and focus our effort and energy to get an
> achievement there instead of trying to cover too many different things.
>
> BR
> Daniele
>
> -----Original Message-----
> From: Teas <teas-bounces@ietf.org> On Behalf Of
> mohamed.boucadair@orange.com
> Sent: den 16 november 2020 09:08
> To: adrian@olddog.co.uk; 'Jari Arkko' <jari.arkko@piuha.net>
> Cc: teas@ietf.org; draft-nsdt-teas-ietf-network-slice-definition@ietf.org
> Subject: Re: [Teas] The definition of a Network Slice in
> draft-nsdt-teas-ietf-network-slice-definition
>
> Hi Adrian, Jari, all,
>
> I agree with the observations made by Adrian and Jari's comment.
>
> It would be helpful to have a name to refer to the connectivity component
> of an IETF network slice. Also, if there are concrete examples of
> non-connectivity IETF components that can be cited in the draft, this would
> be even great.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Teas [mailto:teas-bounces@ietf.org] De la part de Adrian Farrel
> > Envoyé : dimanche 15 novembre 2020 23:01 À : 'Jari Arkko'
> > <jari.arkko@piuha.net> Cc :
> > draft-nsdt-teas-ietf-network-slice-definition@ietf.org;
> > teas@ietf.org
> > Objet : Re: [Teas] The definition of a Network Slice in draft-nsdt-
> > teas-ietf-network-slice-definition
> >
> > Hmm.
> > Maybe a way through this would be to acknowledge slicing of all types
> > of network as possible, and then say that this document is focusing on
> > slicing of connectivity resources.
> >
> > Adrian
> >
> > -----Original Message-----
> > From: Jari Arkko <jari.arkko@piuha.net>
> > Sent: 15 November 2020 21:54
> > To: adrian@olddog.co.uk
> > Cc: teas@ietf.org; draft-nsdt-teas-ietf-network-slice-
> > definition@ietf.org
> > Subject: Re: [Teas] The definition of a Network Slice in draft-nsdt-
> > teas-ietf-network-slice-definition
> >
> > Adrian:
> >
> > Thanks for this as well. Again, I largely agree with what you suggest.
> >
> > (The one exception may be that I do believe firmly that we should be
> > careful to keep the scope of our concept close to what we are experts
> > in, i.e., communication. It also reduces the risk potential confusion
> > and overlap with others who work in the broader area.)
> >
> > Jari
> >
> > _______________________________________________
> > Teas mailing list
> > Teas@ietf.org
> > https://www.ietf.org/mailman/listinfo/teas
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message par
> erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>