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

Adrian Farrel <adrian@olddog.co.uk> Mon, 16 November 2020 17:00 UTC

Return-Path: <adrian@olddog.co.uk>
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 E26523A12B6; Mon, 16 Nov 2020 09:00:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 ptz8f9Z3jxLw; Mon, 16 Nov 2020 09:00:39 -0800 (PST)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BF753A12B0; Mon, 16 Nov 2020 09:00:38 -0800 (PST)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0AGH0aXq029639; Mon, 16 Nov 2020 17:00:36 GMT
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4A42022042; Mon, 16 Nov 2020 17:00:36 +0000 (GMT)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS id 3E3E622040; Mon, 16 Nov 2020 17:00:36 +0000 (GMT)
Received: from LAPTOPK7AS653V ([87.112.234.140]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0AGH0Zo3001433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 16 Nov 2020 17:00:35 GMT
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <teas@ietf.org>, <draft-nsdt-teas-ietf-network-slice-definition@ietf.org>
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> <A4C270E1-C3F2-41EC-AF48-3356965FBF7A@nokia.com>
In-Reply-To: <A4C270E1-C3F2-41EC-AF48-3356965FBF7A@nokia.com>
Date: Mon, 16 Nov 2020 17:00:34 -0000
Organization: Old Dog Consulting
Message-ID: <015701d6bc3a$00787e30$01697a90$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJbg7JORjtUMOnlzFQvq1yLCsmWvQFQNDCcANStulUCZh4iwgKmPDmcAbCVwnGoelqc4A==
Content-Language: en-gb
X-Originating-IP: 87.112.234.140
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25794.000
X-TM-AS-Result: No--23.224-10.0-31-10
X-imss-scan-details: No--23.224-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25794.000
X-TMASE-Result: 10--23.223600-10.000000
X-TMASE-MatchedRID: CxmI61mtwh+yoI+bK8UPQnFPUrVDm6jtGUqOjzOC7Io7sEw6V/IotHi1 9VmdeeTeD/KeePnEJJjFAsGe7dhypqEiiWmjr2gpCuDAUX+yO6ZfZ2ZLIaIqqquPvo9L6iaIw4t agPXRRxxKXjNXJI7beIFHACWsU4r164BFqPOpM5TKqrj96oUKakYj0zDHPzJpdEE+9XN9VT/cK5 HifN4uLvSVXFMm/pWhrVdVqKADhp4yx/0Lxl3XyXYZxYoZm58FI/fosnIAuCBpsnGGIgWMmdsS2 M9fXEk9//xggD71efj5oUvvHT5g0DFuPAQUkJXq7gpIpVc9+U1nfQV7ZPVWyFc/Cedjlcvk4ZqB DBR3qqHQL4yvJqjZ9dpoaxvY2osRG7B2FtuHETuB3FnCb0fWM6m9/6ObPjnDt6pUEPaZyb4s6zD BdwhLR486iamxeiiIv1EnDvFdNJKrDlnDHVCgl+LbvXwDQz25f/TIOqPsDIsOOOIzzESoE9PpIy HbrmaukGu30gbNLE8c3ltr7Cq1yVEEqx9rWQ9hvVl3GmT9KRy++wkLapadd1ddtl4yXVYPbElAq opMKfZxmqTXW8mz5biwCI4RwXun9R7dwXny/bcstWkNArqptkzzNX6FuGYDOF0RIPSotdMZW6Dj kC7kxEn38sgPc1H5AggxppaCpVmvtw4YhJHYUkaMPBFKXyAU4NNiN6MhlPAYzaT/lQGltv57N+i DW4XTs1qtUXfkyo9XZHvIF57f57Gi4RS54QcO4J04kDID6v5AKgfO6jacGcax88xykH9wzH7wfj y0lYkCPVEquO09Bs81NvjC6w1Uj5fLLlh0rlSeAiCmPx4NwFkMvWAuahr8l/frYZ2RpLsXMJx4A 2kfhwtuKBGekqUpIG4YlbCDECsWefvMt+drgg==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/yIB_HRs7vDCPRhgAjWHqAxTxkXY>
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 17:00:42 -0000

The problem (IMHO) in this discussion is that "end-to-end" means something different depending on what layer you're acting in and what your encapsulation is.
The term has a very (very, very) long history in the IETF where it has historically meant something like "from the sending host to the consuming host" and implicitly it has meant "from the point of IP encapsulation to the point of IP decapsulation.

We might find the term "edge-to-edge" useful in the context of IETF network slices.

But it is not a good idea (again, IMHO) to over or under use the term "connectivity". Connectivity only has meaning in the context of the points that are connected. So, if the RAN is not part of the IETF network slice (and I agree that it is not) one still hopes that there is connectivity provided over/through the RAN.

The concept that Med and I are raising is that an IP network (say a service provider's network) contains many features. Obviously the primary one is the ability to take packets and move them across the network: we call that connectivity. But it also contains compute, storage, and network functions. All of these features form part of the SLA between a service provider and some of its customers. It is not for nothing that the IETF has worked on service function chaining and content distribution.

So, while it is "obvious" that when we slice an IETF network we want to slice the connectivity resources, we should also understand that a service provide that offers additional features from their network will want to slice those features in order to provide guaranteed reserved portions of those features and so produce the virtual network that is a an IETF network slice.

I believe that the correct approach here is that the terminology (and framework) draft should acknowledge that this extended concept of slicing exists, but then explicitly say that the focus of this work is on slicing just the connectivity resources.

Best,
Adrian

PS I agree with Reza that network slicing has been discussed for a while. It is possible that it has been discussed for longer than he is aware and that the full concept of "slicing everything" has been out in the wild for a long time.

-----Original Message-----
From: Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com> 
Sent: 16 November 2020 16:10
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>om>; mohamed.boucadair@orange.com; adrian@olddog.co.uk; 'Jari Arkko' <jari.arkko@piuha.net>et>; teas@ietf.org; draft-nsdt-teas-ietf-network-slice-definition@ietf.org
Cc: Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com>
Subject: Re: [Teas] The definition of a Network Slice in draft-nsdt-teas-ietf-network-slice-definition

Hi Med and Daniele,

Agreed with Daniele.

The concept of "IETF Network Slice" addresses the connectivity between various network functions, devices and applications with specific SLO/SLA. 
This is the fundamental aspect of "IETF Network Slice" which has been discussed for a while.

Cheers,
Reza



On 2020-11-16, 7:37 AM, "Daniele Ceccarelli" <daniele.ceccarelli@ericsson.com> wrote:

    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