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

[Adrian Farrel <[e-mail]>]

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