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

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 14 Nov 2020 21:14:33 -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

---

From: Jari Arkko <[email-masked]>
Date: Sun, 15 Nov 2020 23:54:15 +0200

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 15 Nov 2020 22:00:45 -0000

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 <[email-masked]> 
Sent: 15 November 2020 21:54
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Teas] The definition of a Network Slice in
draft-nsdt-teas-ietf-network-slice-definition

Adrian:

(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

---

From: <[email-masked]>
Date: Mon, 16 Nov 2020 08:08:28 +0000

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:[email-masked]] De la part de Adrian Farrel
> Envoyé : dimanche 15 novembre 2020 23:01
> À : 'Jari Arkko' <[email-masked]>
> Cc : [email-masked];
> [email-masked]
> 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
> 
> Subject: Re: [Teas] The definition of a Network Slice in draft-nsdt-
> teas-ietf-network-slice-definition
> 
> Adrian:
> 
> (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
> [email-masked]
> 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.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 16 Nov 2020 10:37:15 +0000

I think that would be a useful approach.

There are some that have been studying slicing for many years and have a strong view that it applies to many resources in addition to connectivity with compute and storage often cited.

I think acknowledging the wider scope of slicing whilst expressly stating that we are dealing with a narrow subset of the problem that is within our expertise would be a good practical approach.

Stewart

> On 15 Nov 2020, at 22:00, Adrian Farrel <[email-masked]> wrote:
> 
> Hmm.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 16 Nov 2020 12:37:41 +0000

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 <[email-masked]> On Behalf Of [email-masked]
Sent: den 16 november 2020 09:08
To: [email-masked]; 'Jari Arkko' <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Teas] The definition of a Network Slice in draft-nsdt-teas-ietf-network-slice-definition

Hi Adrian, Jari, all,

Cheers,
Med

> Envoyé : dimanche 15 novembre 2020 23:01 À : 'Jari Arkko' 
> <[email-masked]> Cc : 
> [email-masked];
> [email-masked]
> 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
> 
> 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
> 

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.

---

From: Young Lee <[email-masked]>
Date: Mon, 16 Nov 2020 22:38:05 +0900

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=
[email-masked]>님이 작성:

> 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
>
> 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
>
> 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,
> 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.

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 16 Nov 2020 16:09:42 +0000

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" <[email-masked]> wrote:

    Hi Med,

    BR
    Daniele  

    -----Original Message-----
    From: Teas <[email-masked]> On Behalf Of [email-masked]
    Sent: den 16 november 2020 09:08
    To: [email-masked]; 'Jari Arkko' <[email-masked]>
    Cc: [email-masked]; [email-masked]
    Subject: Re: [Teas] The definition of a Network Slice in draft-nsdt-teas-ietf-network-slice-definition

    Hi Adrian, Jari, all,

    Cheers,
    Med

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 16 Nov 2020 17:00:34 -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) <[email-masked]> 
Sent: 16 November 2020 16:10
To: Daniele Ceccarelli <[email-masked]>; [email-masked]; [email-masked]; 'Jari Arkko' <[email-masked]>; [email-masked]; [email-masked]
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: Re: [Teas] The definition of a Network Slice in draft-nsdt-teas-ietf-network-slice-definition

Hi Med and Daniele,

Agreed with Daniele.

Cheers,
Reza

    Hi Med,

    BR
    Daniele  

    -----Original Message-----
    From: Teas <[email-masked]> On Behalf Of [email-masked]
    Sent: den 16 november 2020 09:08
    To: [email-masked]; 'Jari Arkko' <[email-masked]>
    Cc: [email-masked]; [email-masked]
    Subject: Re: [Teas] The definition of a Network Slice in draft-nsdt-teas-ietf-network-slice-definition

    Hi Adrian, Jari, all,

    Cheers,
    Med