Subject: Re: [Teas-ns-dt] Brief meeting notes

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 25 Sep 2020 12:28:45 +0000

John,

                >>>> Reza said that we couldn’t use the term ‘network slice’ because 3GPP uses the term ‘E2E network slice’.

This is not correct and this is not what has been said. It has nothing to do with 3GPP.
Whatever I mentioned was that an ‘E2E Network Slice” Is a concept between multiple users and for an operator to create it, it need to create one or more artifacts for various “Connections”.
Calling these Connections “Network Slice” is not accurate as they are part of the “E2E Network Slice”

Reza

From: Teas-ns-dt <[email-masked]> on behalf of John E Drake <jdrake=[email-masked]>
Date: Thursday, September 24, 2020 at 3:41 PM
To: Jari Arkko <jari.arkko=[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Lou Berger <[email-masked]>, "'BRUNGARD, DEBORAH A'" <[email-masked]>, Vishnu Pavan Beeram <vbeeram=[email-masked]>
Subject: Re: [Teas-ns-dt] Brief meeting notes

Hi,

I just wanted to comment on some of the statements that were made during the conference call today.  I think it’s important that we have a written record rather than trying to respond during the conference call.

  1.  Reza said that we couldn’t use the term ‘network slice’ because 3GPP uses the term ‘E2E network slice’.  Obviously, ‘network slice’ is a different term than ‘E2E network slice’ so this is nonsense.  Further, the definition of the term ‘E2E network slice’ would appear to be the concatenation of two or more ‘network slices’.
  2.  Kiran said that the network slicing was introducing an entirely new concept to the IETF.  The last time I checked, there were roughly 20-30 drafts or RFCs on the topic of network slicing, all of which pre-date anything the NSDT has published and all of which use the term ‘network slicing’
  3.  Kiran said that ‘transport network’ was a common term in the IETF.  This is incorrect.  ‘Transport Network’ is an ITU term and the only time it is used in the IETF is in support of the ITU’s use of MPLS.  This is MPLS-TP (transport profile).
  4.  Kiran said that term ‘IETF network slice’ is not generic.  Why is it important that the term we use be generic and why is this term not generic?
  5.  Kiran said that the NBI was not a service definition.  I think this is nonsense – otherwise, why do we have ‘service level objectives’?

Further, any discussion of isolation should be in terms of the variation of an SLO parameter’s value, since this is the only thing a customer can measure as the instantiation of its ‘service’.  E.g., absolute isolation would mean that a given SLO parameter’s value is invariant.

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas-ns-dt <[email-masked]> On Behalf Of Jari Arkko
Sent: Thursday, September 24, 2020 12:34 PM
To: [email-masked]
Subject: [Teas-ns-dt] Brief meeting notes

[External Email. Be cautious of content]

Situation:
- Documents not adopted as is

Process:
- we need to revise based on feedback and ask again
- wait on framework until definitions agreed
- interim on Oct 19

Main changes:
1/ need to use a different term
- Perhaps more about the name itself than its definition – but also have to worry about the latter. Maybe easier to discuss once the name is not objectionable?
- We all recognize the feedback, and agree not to use transport network slice term
- IETF network slice one contender, some resistance
2/ isolation
- Need acceptable content, not just a placeholder
- Need to understand which approach to use, though (Jari recommended explaining how the term relates to this work, perhaps some breakdown of the term as well)

Next steps:
- For each issue/change, a small team to look at it, provide some options, and analysis of the implications and tradeoffs in those options
- Post early to main TEAS WG list, keep discussion ongoing
- Jari can arrange a weekly call starting next week (again, posted to main list) for those who want to discuss in real-time. But useful only after the above two steps are done first.
- Responsible people: on the name issue, the author team; on isolation Luis, Jie, and Jeff will work on it
- Everyone else to stay active on list + comment and make counter proposals and additional analysis

---

From: John E Drake <[email-masked]>
Date: Fri, 25 Sep 2020 13:23:40 +0000

Replacing the term 'transport slice' or 'transport network slice' with the term 'network slice' does not change anything so your argument is specious.

Yours Irrespectively,

John

Juniper Business Use Only
From: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Sent: Friday, September 25, 2020 8:29 AM
To: John E Drake <[email-masked]>; Jari Arkko <[email-masked]>; [email-masked]
Cc: [email-masked]; Lou Berger <[email-masked]>; 'BRUNGARD, DEBORAH A' <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: Re: [Teas-ns-dt] Brief meeting notes

John,

                >>>> Reza said that we couldn't use the term 'network slice' because 3GPP uses the term 'E2E network slice'.

This is not correct and this is not what has been said. It has nothing to do with 3GPP.
Whatever I mentioned was that an 'E2E Network Slice" Is a concept between multiple users and for an operator to create it, it need to create one or more artifacts for various "Connections".
Calling these Connections "Network Slice" is not accurate as they are part of the "E2E Network Slice"

Reza

From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> on behalf of John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>
Date: Thursday, September 24, 2020 at 3:41 PM
To: Jari Arkko <jari.arkko=[email-masked]<mailto:jari.arkko=[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Lou Berger <[email-masked]<mailto:[email-masked]>>, "'BRUNGARD, DEBORAH A'" <[email-masked]<mailto:[email-masked]>>, Vishnu Pavan Beeram <vbeeram=[email-masked]<mailto:vbeeram=[email-masked]>>
Subject: Re: [Teas-ns-dt] Brief meeting notes

Hi,

I just wanted to comment on some of the statements that were made during the conference call today.  I think it's important that we have a written record rather than trying to respond during the conference call.

  1.  Reza said that we couldn't use the term 'network slice' because 3GPP uses the term 'E2E network slice'.  Obviously, 'network slice' is a different term than 'E2E network slice' so this is nonsense.  Further, the definition of the term 'E2E network slice' would appear to be the concatenation of two or more 'network slices'.
  2.  Kiran said that the network slicing was introducing an entirely new concept to the IETF.  The last time I checked, there were roughly 20-30 drafts or RFCs on the topic of network slicing, all of which pre-date anything the NSDT has published and all of which use the term 'network slicing'
  3.  Kiran said that 'transport network' was a common term in the IETF.  This is incorrect.  'Transport Network' is an ITU term and the only time it is used in the IETF is in support of the ITU's use of MPLS.  This is MPLS-TP (transport profile).
  4.  Kiran said that term 'IETF network slice' is not generic.  Why is it important that the term we use be generic and why is this term not generic?
  5.  Kiran said that the NBI was not a service definition.  I think this is nonsense - otherwise, why do we have 'service level objectives'?

Further, any discussion of isolation should be in terms of the variation of an SLO parameter's value, since this is the only thing a customer can measure as the instantiation of its 'service'.  E.g., absolute isolation would mean that a given SLO parameter's value is invariant.

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of Jari Arkko
Sent: Thursday, September 24, 2020 12:34 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Teas-ns-dt] Brief meeting notes

Situation:

Process:

Main changes:
- Perhaps more about the name itself than its definition - but also have to worry about the latter. Maybe easier to discuss once the name is not objectionable?

Next steps:

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 25 Sep 2020 14:27:27 +0100

Reza,

Where can I go for a definition of the term “E2E network slice” so that I can get a better understanding of the concept and work out how the terms “connection” and “network slice” fit in?

A lot will depend (I suppose) on how an “end” is defined, and what context is being applied.

Thanks,

Adrian

From: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]> 
Sent: 25 September 2020 13:29
To: John E Drake <jdrake=[email-masked]>; Jari Arkko <jari.arkko=[email-masked]>; [email-masked]
Cc: [email-masked]; Lou Berger <[email-masked]>; 'BRUNGARD, DEBORAH A' <[email-masked]>; Vishnu Pavan Beeram <vbeeram=[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: Re: [Teas-ns-dt] Brief meeting notes

John,

Reza

From: Teas-ns-dt <[email-masked] <mailto:[email-masked]> > on behalf of John E Drake <jdrake=[email-masked] <mailto:jdrake=[email-masked]> >
Date: Thursday, September 24, 2020 at 3:41 PM
To: Jari Arkko <jari.arkko=[email-masked] <mailto:jari.arkko=[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >, Lou Berger <[email-masked] <mailto:[email-masked]> >, "'BRUNGARD, DEBORAH A'" <[email-masked] <mailto:[email-masked]> >, Vishnu Pavan Beeram <vbeeram=[email-masked] <mailto:vbeeram=[email-masked]> >
Subject: Re: [Teas-ns-dt] Brief meeting notes

Hi,

Yours Irrespectively,

John

From: Teas-ns-dt <[email-masked] <mailto:[email-masked]> > On Behalf Of Jari Arkko
Sent: Thursday, September 24, 2020 12:34 PM
To: [email-masked] <mailto:[email-masked]> 
Subject: [Teas-ns-dt] Brief meeting notes

Situation:

Process:

- interim on Oct 19

Main changes:

2/ isolation

Next steps:

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Fri, 25 Sep 2020 14:01:38 +0000

Hi Reza,

<AD hat off>

It’s good to see not stuck on using a 3GPP term.

As I think both Adrian and I noted before, I think we are approaching this with a different end model in mind. It depends how one wants to view this operationally. I’d say some basic operational requirements are:
- ability for the E2E slice to traverse multiple domains
- ability for each domain to efficiently provide the E2E slice the appropriate parameters - and this includes the ability to combine multiple E2E slices for supporting over the domain.
- ability for the E2E slice to be identified and each domain needs to have the ability to identify the slice and the mapping in its domain
- critical - it must not be assumed there is a one to one mapping between control/service entities and physical entities. As an operator, why I am so sensitive on the term transport, because it infers physical entities. Both ITU and IETF operators no longer look at our world as 1:1 “transport” pipes, it is a “network”, and that is critical for our operations to be intelligent.

In ccamp and teas, we’ve modeled this in the past using the same term for the different domains (and ITU and ETSI do also) - this is why we are questioning why need now a different term within a domain. It complicates operationally.

RFC4726 describes an E2E LSP and the multiple ways to support it across a domain. Each domain still uses the same term, LSP. And there are many models for supporting.

As you were wondering on proprietary domains (an earlier thread), one could also use the ASON model, RFC4139. The E2E is a “call”. Each domain is a “call segment”, including the proprietary domain. Operationally, all domains know exactly the reference.

Here, can use the term E2E network slice segments for the “connections” in the domain. Don’t forget in each domain, they will be supported by other network slices - hierarchical slices. So what you are referring to as connections may be a “network slice”. There needs to be an independence between control and realization in the network.

Thanks,
Deborah

Sent from my iPhone

On Sep 25, 2020, at 8:28 AM, Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]> wrote:

John,

Reza

Hi,

Yours Irrespectively,

John

Situation:

Process:

Main changes:

Next steps:

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 25 Sep 2020 14:41:46 +0000

Adrian,

The definition of the “E2E network slice” is better understood based on use-case. I have added two use-cases below.
In summary, the “endpoint” of a Connection might be any combination of various  VNF, PNF or applications.
A couple of notes related to these use-cases:

  *   IETF definition work is beyond any use-case. We are not stuck on 3GPP terms
  *   The “E2E network” slice and Connections are not the same. We shall use different terms for them to make sure they are distinct
  *   The scope of IETF work is not “E2E network slice” as shown below. Depends on the use case the “E2E network slice” might be different from “Connections”.
  *   The IETF scope is related to “Connections” and question is which term to use for them.

Cheers,
Reza

From: Adrian Farrel <[email-masked]>
Organization: Old Dog Consulting
Reply-To: "[email-masked]" <[email-masked]>
Date: Friday, September 25, 2020 at 9:27 AM
To: Reza Rokui <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Teas-ns-dt] Brief meeting notes

Reza,

Thanks,
Adrian

John,

Reza

Hi,

Yours Irrespectively,

John

Situation:

Process:

Main changes:

Next steps:

---

From: Eric Gray <[email-masked]>
Date: Fri, 25 Sep 2020 14:43:24 +0000

Reza,

              I think we get your point.  But there is both room, and evidence, to support disagreement at a basic level.

              One of the most complex aspects of layering in a network is that there needs to be as complete a decoupling between any layer and what is above and below it as is technically possible.

              It is certainly reasonable to layer a network slice over another – possibly quite distinct – network slice.  And in fact, my reading of various technical documents on this topic is that there is at least some expectation that this is exactly what will happen.

              As an example, a mobile operator may need to request what they think of as a “Transport Network Slice” from what they think of as a “Transport Network.”  It is fundamentally ridiculous to assert that the technology used to provide the requested service (because it would be requested using service parameters) needs to be built using any specific technology, or exclusive of any specific technology.

              You’ve admitted at several points during the NS-DT discussions that it is always possible to imagine such a slice being provided hierarchically over zero or more additional network slices.  Why would you suggest that each level in the potential hierarchy needs to be described using a different name.

              In fact, in my discussions with 3GPP experts, it is pretty clear that they could not care less what a “Transport Network Slice” provider calls what they are providing – as long as it meets the service level objectives requested and assured.

--
Eric

From: Teas-ns-dt <[email-masked]> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Friday, September 25, 2020 8:29 AM
To: John E Drake <jdrake=[email-masked]>; Jari Arkko <jari.arkko=[email-masked]>; [email-masked]
Cc: [email-masked]; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; Lou Berger <[email-masked]>; Vishnu Pavan Beeram <vbeeram=[email-masked]>; 'BRUNGARD, DEBORAH A' <[email-masked]>
Subject: Re: [Teas-ns-dt] Brief meeting notes

John,

Reza

Hi,

Yours Irrespectively,

John

Situation:

Process:

Main changes:

Next steps:

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 25 Sep 2020 20:17:18 +0530

Hi Deborah,

I have a feeling that the disconnect can be highlighted by the following
figure from Jari's presentation from IETF 106 -

https://www.ietf.org/proceedings/106/slides/slides-106-teas-sessb-13-network-slicing-design-team-update-01.pdf

The RAN Slice and Core Slice were examples of things outside of IETF and
the strong assumption that the slice that we define in IETF (let's call it
IETF network slice) cannot be used by those. (This would be especially true
for the NBI YANG model that we are also defining.)

Because of that assumption, E2E network slice = IETF network slice +
other-slice(s). And that is how the need for a new term was justified. I
have a feeling not everyone agrees with this assumption and would be good
if we can clarify that!

I am not sure if this helps, I see new emails from Reza/Eric already, but
since I had typed this, let me just send it out anyways! Happy weekend!

Dhruv

On Fri, Sep 25, 2020 at 7:31 PM BRUNGARD, DEBORAH A <[email-masked]> wrote:

> As I think both Adrian and I noted before, I think we are approaching this
> with a different end model in mind. It depends how one wants to view this
> operationally. I’d say some basic operational requirements are:
> - ability for each domain to efficiently provide the E2E slice the
> appropriate parameters - and this includes the ability to combine multiple
> E2E slices for supporting over the domain.
> - ability for the E2E slice to be identified and each domain needs to have
> the ability to identify the slice and the mapping in its domain
> - critical - it must not be assumed there is a one to one mapping between
> control/service entities and physical entities. As an operator, why I am so
> sensitive on the term transport, because it infers physical entities. Both
> ITU and IETF operators no longer look at our world as 1:1 “transport”
> pipes, it is a “network”, and that is critical for our operations to be
> intelligent.
>
> In ccamp and teas, we’ve modeled this in the past using the same term for
> the different domains (and ITU and ETSI do also) - this is why we are
> questioning why need now a different term within a domain. It complicates
> operationally.
>
> RFC4726 describes an E2E LSP and the multiple ways to support it across a
> domain. Each domain still uses the same term, LSP. And there are many
> models for supporting.
>
> As you were wondering on proprietary domains (an earlier thread), one
> could also use the ASON model, RFC4139. The E2E is a “call”. Each domain is
> a “call segment”, including the proprietary domain. Operationally, all
> domains know exactly the reference.
>
> Here, can use the term E2E network slice segments for the “connections” in
> the domain. Don’t forget in each domain, they will be supported by other
> network slices - hierarchical slices. So what you are referring to as
> connections may be a “network slice”. There needs to be an independence
> between control and realization in the network.
>
> Thanks,
> Deborah
>
> Sent from my iPhone
>
>                 >>>> Reza said that we couldn’t use the term ‘network
> slice’ because 3GPP uses the term ‘E2E network slice’.
>
>
>
> Whatever I mentioned was that an ‘E2E Network Slice” Is a concept between
> multiple users and for an operator to create it, it need to create one or
> more artifacts for various “Connections”.
>
> *From: *Teas-ns-dt <[email-masked]> on behalf of John E
> Drake <jdrake=[email-masked]>
> *Date: *Thursday, September 24, 2020 at 3:41 PM
> *To: *Jari Arkko <jari.arkko=[email-masked]>, "
> [email-masked]" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, Lou Berger <
> [email-masked]>, "'BRUNGARD, DEBORAH A'" <[email-masked]>, Vishnu Pavan
> Beeram <vbeeram=[email-masked]>
> *Subject: *Re: [Teas-ns-dt] Brief meeting notes
>
>
>
> Hi,
>
>
>
> I just wanted to comment on some of the statements that were made during
> the conference call today.  I think it’s important that we have a written
> record rather than trying to respond during the conference call.
>
>
>
>    1. Reza said that we couldn’t use the term ‘network slice’ because
>    3GPP uses the term ‘E2E network slice’.  Obviously, ‘network slice’ is a
>    different term than ‘E2E network slice’ so this is nonsense.  Further, the
>    definition of the term ‘E2E network slice’ would appear to be the
>    concatenation of two or more ‘network slices’.
>    2. Kiran said that the network slicing was introducing an entirely new
>    concept to the IETF.  The last time I checked, there were roughly 20-30
>    drafts or RFCs on the topic of network slicing, all of which pre-date
>    anything the NSDT has published and all of which use the term ‘network
>    slicing’
>    3. Kiran said that ‘transport network’ was a common term in the IETF.
>    This is incorrect.  ‘Transport Network’ is an ITU term and the only time it
>    is used in the IETF is in support of the ITU’s use of MPLS.  This is
>    MPLS-TP (transport profile).
>    4. Kiran said that term ‘IETF network slice’ is not generic.  Why is
>    it important that the term we use be generic and why is this term not
>    generic?
>    5. Kiran said that the NBI was not a service definition.  I think this
>    is nonsense – otherwise, why do we have ‘service level objectives’?
>
>
>
> Further, any discussion of isolation should be in terms of the variation
> of an SLO parameter’s value, since this is the only thing a customer can
> measure as the instantiation of its ‘service’.  E.g., absolute isolation
> would mean that a given SLO parameter’s value is invariant.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> *From:* Teas-ns-dt <[email-masked]> *On Behalf Of *Jari Arkko
> *Sent:* Thursday, September 24, 2020 12:34 PM
> *To:* [email-masked]
> *Subject:* [Teas-ns-dt] Brief meeting notes
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> *Situation*:
>
> *Process*:
> *Main changes*:
> - Perhaps more about the name itself than its definition – but also have
> to worry about the latter. Maybe easier to discuss once the name is not
> objectionable?
>
> - Need to understand which approach to use, though (Jari recommended
> explaining how the term relates to this work, perhaps some breakdown of the
> term as well)
>
>
>
> *Next steps*:
>
> - For each issue/change, a small team to look at it, provide some options,
> and analysis of the implications and tradeoffs in those options
>
> - Jari can arrange a weekly call starting next week (again, posted to main
> list) for those who want to discuss in real-time. But useful only after the
> above two steps are done first.
>
> Teas-ns-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas-ns-dt
>

---

From: Eric Gray <[email-masked]>
Date: Fri, 25 Sep 2020 14:54:12 +0000

Reza,

I think I have repeatedly made the point that this aspect of the discussion is a pointless distraction.

If we describe what a slice consumer can expect from the slice provided in terms of SLO parameters, and we include how the slice consumer connects to the slice provided, we do not need to know anything about how or why the slice consumer might use the slice provided.

In fact, we should not want to know, because anything we need to know about how the slice consumer uses the slice provided – that is not reflected in SLO parameters – becomes a complicating factor.

So, as much as it might be useful to provide a “big-picture” diagram for some number of use cases, we have those now, and we should not spend much time in describing aspects of use cases that have zero impact on the work we are doing.

--
Eric

From: Teas-ns-dt <[email-masked]> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Friday, September 25, 2020 10:42 AM
To: [email-masked]; [email-masked]
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: Re: [Teas-ns-dt] Brief meeting notes

Adrian,

Cheers,
Reza

From: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Organization: Old Dog Consulting
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 25, 2020 at 9:27 AM
To: Reza Rokui <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Teas-ns-dt] Brief meeting notes

Reza,

Thanks,
Adrian

From: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Sent: 25 September 2020 13:29
To: John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>; Jari Arkko <jari.arkko=[email-masked]<mailto:jari.arkko=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Lou Berger <[email-masked]<mailto:[email-masked]>>; 'BRUNGARD, DEBORAH A' <[email-masked]<mailto:[email-masked]>>; Vishnu Pavan Beeram <vbeeram=[email-masked]<mailto:vbeeram=[email-masked]>>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas-ns-dt] Brief meeting notes

John,

Reza

Hi,

Yours Irrespectively,

John

Situation:

Process:

Main changes:

Next steps:

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 25 Sep 2020 15:57:55 +0100

Thanks Reza,

I need to digest this some.

I see how a connection may be a concatenation of connections. AFAICS an e2e slice is achieved by a concatenation of connections. I am struggling to see what is a “slice” and what is a “connection”.

Are these figures your own construction (which would be fine), in which case the term 2e2 network slice is something “you” have defined to help explain the figures, or are they borrowed from work in other bodies, in which case a reference would be really helpful?

Cheers,

Adrian

Sent: 25 September 2020 15:42

Adrian,

Cheers,

Reza

 

From: Adrian Farrel <[email-masked] <mailto:[email-masked]> >
Organization: Old Dog Consulting
Reply-To: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Date: Friday, September 25, 2020 at 9:27 AM
To: Reza Rokui <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Subject: RE: [Teas-ns-dt] Brief meeting notes

Reza,

Thanks,

Adrian

From: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked] <mailto:[email-masked]> > 
Sent: 25 September 2020 13:29
To: John E Drake <jdrake=[email-masked] <mailto:jdrake=[email-masked]> >; Jari Arkko <jari.arkko=[email-masked] <mailto:jari.arkko=[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> ; Lou Berger <[email-masked] <mailto:[email-masked]> >; 'BRUNGARD, DEBORAH A' <[email-masked] <mailto:[email-masked]> >; Vishnu Pavan Beeram <vbeeram=[email-masked] <mailto:vbeeram=[email-masked]> >; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Teas-ns-dt] Brief meeting notes

John,

Reza

Hi,

Yours Irrespectively,

John

Situation:

Process:

- interim on Oct 19

Main changes:

2/ isolation

Next steps:

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 25 Sep 2020 15:04:56 +0000

Hi Deborah,

Thanks for your email. Before answering your email, I have one question for you.
Please clarify the phrase “E2E slice”; are you referring  to“E2E network slice” or “Connections” in picture below? Or something else?

Cheers,
Reza

From: Teas-ns-dt <[email-masked]> on behalf of "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Friday, September 25, 2020 at 10:01 AM
To: Reza Rokui <[email-masked]>
Cc: Lou Berger <[email-masked]>, Jari Arkko <jari.arkko=[email-masked]>, John E Drake <jdrake=[email-masked]>, Vishnu Pavan Beeram <vbeeram=[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Teas-ns-dt] Brief meeting notes

Hi Reza,

<AD hat off>

Thanks,
Deborah

Sent from my iPhone

Reza

Hi,

Yours Irrespectively,

John

Situation:

Process:

Main changes:

Next steps:

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 25 Sep 2020 15:31:24 +0000

Thanks Adrian

                >>>> AFAICS an e2e slice is achieved by a concatenation of connections
An “E2E network slice” is not a concatenation of connections but rather a COLLECTION of multiple connections and others (which is out of scope of IETF).

>>>> I am struggling to see what is a “slice” and what is a “connection”.
For this we need to refer to one of the use-cases below. For example for 5G Network Slicing use-case, the network slice is COLLECTION (not concatenation) of: Connection_1, Connetion_2 , Connection_3, Connection_4, RAN Slice,  Core Slice
To further clarify this, Connection_3 for example is addressing the connectivity between RAN and Core domains with certain SLA/SLO.

                >>>> Are these figures your own construction (which would be fine), in which case the term 2e2 network slice is something “you” have defined to help explain the figures
AFAIK, the following references mainly call it “5G Network Slice” but when they describe this term they use End2End:

  *   MEF: https://wiki.mef.net/display/CESG/Slicing+for+Shared+5G+Fronthaul+and+Backhaul+-+White+Paper3GPP:
  *   3GPP: TS 28.530 and also see section 4.7 and Figure 4.7.1

Cheers,
Reza

Date: Friday, September 25, 2020 at 10:57 AM

Thanks Reza,

Cheers,
Adrian

Adrian,

Cheers,
Reza

Reza,

Thanks,
Adrian

John,

Reza

Hi,

Yours Irrespectively,

John

Situation:

Process:

Main changes:

Next steps: