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

Adrian Farrel <adrian@olddog.co.uk> Sat, 14 November 2020 21:14 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 8D7423A132A; Sat, 14 Nov 2020 13:14:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 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] 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 PTGb_AkxzRM4; Sat, 14 Nov 2020 13:14:38 -0800 (PST)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 6C0FB3A1329; Sat, 14 Nov 2020 13:14:37 -0800 (PST)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0AELEZ05007450; Sat, 14 Nov 2020 21:14:35 GMT
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3BD192204A; Sat, 14 Nov 2020 21:14:35 +0000 (GMT)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS id 250F822048; Sat, 14 Nov 2020 21:14:35 +0000 (GMT)
Received: from LAPTOPK7AS653V ([87.113.40.94]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0AELEXXA029572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 14 Nov 2020 21:14:34 GMT
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <teas@ietf.org>
Cc: <draft-nsdt-teas-ietf-network-slice-definition@ietf.org>
Date: Sat, 14 Nov 2020 21:14:33 -0000
Organization: Old Dog Consulting
Message-ID: <008201d6bacb$26b80590$742810b0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: Ada5piXHleRdfzx0RhmsYb9i2G5H9Q==
Content-Language: en-gb
X-Originating-IP: 87.113.40.94
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-25790.003
X-TM-AS-Result: No--10.468-10.0-31-10
X-imss-scan-details: No--10.468-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25790.003
X-TMASE-Result: 10--10.468100-10.000000
X-TMASE-MatchedRID: 2IBMc5ux2bMaf3p8Lo2lejjNGpWCIvfTRf40pT7Zmv7nUD8POrkddpy8 UG+qg0r7A3g/bA2fJojJQyxgXBh/lJTQj0yjAfNmkIHrlGNFjey/yN2q8U674hw0HKhKjTfpMWM 94lj32bRy77BciXetbxKXbQ7gQn+I5/PHRWHr9ZZpTt57XuqMc3HhSskMF1smVj3J63pAR3zcAR WbwH/DqI5TZO4r6MeQZWHShf8nCah0zarmKAz/XvGSfx66m+aMVBPjB/Of+FR0QT71c31VP8HSO ko0aBIrwkL7nAwIDMC4qW21Esgi/botpw4iUQe/9Ib/6w+1lWRMhH/KpYxyu9SNWqsiFFWqXAue RFycznkj115IHG2MhkdCei9/0vMK9bSh9CO8PiooPrDxs+3NLD39vrXxKlsdy5JfHvVu9ItRwYO w2kbXOg+U/EhAdXBhU6WsjEEjHBG6x2PC25NEZroLyaVI8w2Xt+qzhLpfDh+xLSxkQHtzxt7EHA uRAfwULxDYQ0oLbP1WS2EuF4IFccpDQwsfzPQyfjUCBXbhed8rU8f3oY88YLobGHR5ejtrq+iVt 87uhrRyhS2i4TcpLGRHdqsCUQQdFC1+JwI1dIeOjIrMSa2sRxdoyFlJ5UUM8Q0z/q2IZxNInu5C cvCbg4NZ82/4ClMEJnyTkvY8EAvpWrs6AJRfM8n9tWHiLD2GE3EgF0+MVuB8vx8dQICa68rSubB Ii8PvZnTpsBbt5FaFbYKWvBNlvm5Y5G74YU3HRXdiukZQCgFlnkeRE0Y2A1TLFYJ6eWcdaUXs6F guVy1AUrzggZaq4UgbxCBAaCVTXRQUFxxOjheeAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47hTZDOrz lZ+cHQdJ7XfU86e4kYXbobxJbKl/MtrTwS4UKg24iY9ndkYC+Wgo+v/MI0C43gUjlk0V+PrvL4N gF1ifXL3KcoCS6E=
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/6lkkyX26nAGOCYkBoN1EmTzqkIY>
Subject: [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: Sat, 14 Nov 2020 21:14:41 -0000

Hi,

The second in a series of specific threads on the content of
draft-nsdt-teas-ietf-network-slice-definition with the hope of getting it
into a good shape for adoption by the working group. We *really* need to
achieve that to unblock quite a lot of related work.

This is probably the most fundamental of discussion points - what is an IETF
network slice?

For reference, the definition is found in Section 3 of the -01 version of
the draft. But note that Section 1.1 contains additional and overlapping
material.

In no particular order, let's consider a couple of points:

1. Are our slices limited to slicing connectivity, or do they slice all
resources in the network?

This is something that Med raised, but is also a concern of mine since
(IMHO) the early slicing discussions in the IETF all included the concept of
slicing all network resources. This would include virtual functions, compute
resources, storage, etc.

It seems to me that it is reasonable that our initial work should focus on
connectivity, but I also don't think that we should do anything here that
limits us in the future. So we need to express the slice in terms of
connectivity, but mention the possibility of slicing other resources.

2. The "rationale" in Section 1.1 provides an overlapping description of a
slice. I don't think it is helpful to have this material in two places. I
suggest to completely remove Section 1.1 and to merge the text into Section
3.


What I've done, below, is pull the contents of 1.1 and 3, and insert some
commentary. Then I have suggested new text for Section 3 (on the assumption
of deleting Section 1.1).

Best,
Adrian

COMMENTS on SECTION 1.1
>> I think this section should be removed and the text folded into 
>> section 3.
   IETF Network Slices are created and managed within the scope of one
   or more network technologies (e.g., IP, MPLS, optical).  They are
   intended to enable a diverse set of applications that have different
   requirements to coexist on the same network infrastructure.
>> I like this paragraph

   An IETF Network Slice is a well-defined structure of connectivity
   requirements and associated network behaviors. 
>> This needs to include:
>> - endpoints
>> - the explanation of "connectivity requirements" 
>>   - as connecting subsets of the end points
>>   - applying different connectivity paradigms such as p2mp etc
>> - an expansion of "behaviors" which encompasses network functions
   IETF Network Slices
   are defined such that they are independent of the underlying
   infrastructure connectivity and technologies used.
>> That's a nice way of putting it   
   This is to allow
   an IETF Network Slice consumer to describe their network connectivity
   and relevant objectives in a common format, independent of the
   underlying technologies used.
>> Maybe s/This is to allow/This allows/

   IETF Network Slices may be combined hierarchically, so that a network
   slice may itself be sliced.  They may also be combined sequentially
   so that various different networks can each be sliced and the network
   slices placed into a sequence to provide an end-to-end service.  This
   form of sequential combination is utilized in some services such as
   in 3GPP's 5G network [TS.23.501-3GPP].
>> These two paragraphs are helpful to the definition and it is useful
>> to pull in the reference to 3GPP

COMMENTS on SECTION 3 TEXT
   An IETF Network Slice is a logical network topology connecting a
   number of endpoints with a set of shared or dedicated network
>> "with" implies that the endpoints are connected with/to the set of
>> resources. We should use "using".
   resources, that are used to satisfy specific Service Level Objectives
   (SLOs).

>> At this point in the definition, we should expand on the concept of
>> a logical topology, because a slice is not just the topology, but
>> also the connectivity paradigm associated with the end points.
>> For example, a topology is generally supposed to support any-to-any
>> mesh connectivity, but the level of connectivity required may be
>> less than that, but very specific (such as point-to-multipoint).
>> While this could be expressed in the SLOs, I think that section 4.2
>> describes this as part of the connectivity definition of the slice.
>> Thus, at this point we should make some basic mention, such as...
>>   Subsets of the end points are associated with connectivity
>>   paradigms such as point-to-multipoint, point-to-point mesh,
>>   multipoint-to-multipoint, etc.

   IETF Network Slice specification is technology-agnostic, and the
>> This needs an article. I think, probably an indefinite article as
>> "An IETF Network Slice..."
>> The word "specification" is not applicable. Or rather, it is
>> ambiguous because it could refer to the slice that is requested
>> (which I think you mean) or the slice that is delivered (which is
>> mainly out of scope).
   means for IETF network slice realization can be chosen depending on
   several factors such as: service requirements, specifications or
   capabilities of underlying infrastructure.
>> This is a bit clumsy, but can be saved by breaking the sentence into
>> two with a little re-wording.
>> We should decide on whether "IETF Network Slice" is always
>> capitalised. Looks like it isn't.
   The structure and
   different characteristics of IETF Network Slices are described in the
   following sections.
>> I don't think this final sentence adds anything to the definition.

   Term "Slice" refers to a set of characteristics and behaviours that
   separate one type of user-traffic from another.
>> I feel this sentence is adding more confusion than clarity. The
>> "separation of traffic" seems to echo the discussion of "isolation"
>> but the intention of slicing is surely to slice the resources (which
>> may be used to separate traffic).
   IETF Network Slice
>> Also missing an article
   assumes that an underlying network is capable of changing the
   configurations of the network devices on demand, through in-band
   signaling or via controller(s) and fulfilling all or some of SLOs to
   all of the traffic in the slice or to specific flows.
>> I think this "assumption" doesn't cover all slicing possibilities
>> since there is the possibility that all "reservations" are made in
>> a central statistical model. It is perhaps worth moving this
>> discussion into a later part of the document or into the framework
>> where a broader discussion of realisation can be made.

SUGGESTED NEW SECTION 3
   An IETF network slice is a logical network topology connecting a
   number of endpoints using a set of shared or dedicated network
   resources that are used to satisfy specific Service Level Objectives
   (SLOs).  Subsets of the end points are associated with connectivity
   paradigms such as point-to-multipoint, point-to-point mesh,
   multipoint-to-multipoint, etc.

   An IETF network slice is a well-defined structure of connectivity
   requirements and associated network behaviors such as bandwidth, 
   latency, jitter, compute and storage availability, and network
   functions.  IETF network slices are defined such that they are
   independent of the underlying infrastructure connectivity and 
   technologies used.  This is to allow an IETF network slice consumer
   to describe their network connectivity and relevant objectives in a
   common format, independent of the underlying technologies used.

   IETF network slices are created and managed within the scope of one
   or more network technologies (e.g., IP, MPLS, optical).  They are
   intended to enable a diverse set of applications that have different
   requirements to coexist on the same network infrastructure.  A 
   request for an IETF network slice is technology-agnostic so as to 
   allow a consumer to describe their network connectivity objectives in
   a common format, independent of the underlying technologies used.
   
   IETF network slices may be combined hierarchically, so that an IETF
   network slice may itself be sliced.  They may also be combined
   sequentially so that various different networks can each be sliced
   and the IETF network slices placed into a sequence to provide an end-
   to-end service.  This form of sequential combination is utilized in
   some services such as in 3GPP's 5G network [TS.23.501-3GPP].
END