Subject: [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 2 Mar 2022 21:15:11 -0000

Hi,

I am just about to post -06 of this document. None of the changes, below
should be a surprise. 1, 3, and 4 were talked about at IETF-112. 2 is just
fine-tuning the text already in -05.

1.	Deprecating NBI/SBI

Per the discussion at IETF-112 and following on from Med's comments, I am
replacing "NBI" with "IETF Network Slice Service Interface", and "SBI" with
"Network Configuration Interface". 

These are abstract terms, and the implementations might choose to use NSSM
and NSNM. They might also choose to stick with NBI, but I personally find
that term ambiguous in the greater scheme of things.

2.	Clarifying the relationships between slices, connectivity
constructs, SLOs/SLEs, and network resource partitions.

Recent reviews and discussions of draft-bestbar-teas-ns-packet have made it
clear that the current text is not sufficiently unambiguous. Although I know
what I meant, the text is open to interpretation and needs to be tightened
up.

The relationships are easy to express:

*	A network slice is a service requested by / provided for the
customer
*	The network slice service is expressed in terms of one or more
connectivity constructs. 
An implementation or operator is free to limit the number of connectivity
constructs in a slice to exactly one.
*	Each connectivity construct has a set of SLOs and SLEs.
The set does not need to be the same for every connectivity construct in the
slice.
An implementation or operator is free to require that all connectivity
constructs in a slice have the same set of SLOs and SLEs.
*	One or more connectivity constructs from one or more slices are
mapped to a set of network resources called a Network Resource Partition
(NRP).
One connectivity construct is only mapped to one NRP.
An NRP may be chosen because of its ability to support a specific set of
SLOs and SLEs, or its ability to support particular connectivity types.
An implementation or operator is free to map each connectivity construct to
a separate NRP, although there may be scaling implications depending on the
solution implemented.
Thus, the connectivity constructs in one slice may be mapped to one or more
NRPs.
By implication from the above, an implementation or operator is free to map
all the connectivity constructs in a slice to a single NRP and to not share
that NRP with connectivity constructs from another slice.
*	An NRP is simply a collection of (reserved) resources extracted from
the underlying physical network.
The process of determining the NRP may be made easier if the physical
network topology is first filtered into a Filter Topology in order to be
aware of the subset of network resources that are suitable for specific
NRPs.

3.	What to call an end point

During IETF-112 we spotted several overlapping terms (CE, end-point, NSE,
maybe PE) and decided that the more generic term "Service Demarcation Point"
should be used.

This will help remove the confusion about where the service begins and ends,
allowing the existing text that enumerates the options to not get blurred by
other text in the document. Of course, CEs and PEs still exist and need to
be mentioned, but the service demarcation point term allows us to be generic
without forcing any one of the four implementation options already described
in the text and Figure 1.

4.	General editorial pass to clean up spelling and language use

Best,

Adrian

---

From: John E Drake <[email-masked]>
Date: Wed, 2 Mar 2022 21:32:31 +0000

Most excellent

Sent from my iPhone

On Mar 2, 2022, at 4:15 PM, Adrian Farrel <[email-masked]> wrote:

[External Email. Be cautious of content]

Hi,

I am just about to post -06 of this document. None of the changes, below should be a surprise. 1, 3, and 4 were talked about at IETF-112. 2 is just fine-tuning the text already in -05.

  1.  Deprecating NBI/SBI

Per the discussion at IETF-112 and following on from Med’s comments, I am replacing “NBI” with “IETF Network Slice Service Interface”, and “SBI” with “Network Configuration Interface”.

These are abstract terms, and the implementations might choose to use NSSM and NSNM. They might also choose to stick with NBI, but I personally find that term ambiguous in the greater scheme of things.

  1.  Clarifying the relationships between slices, connectivity constructs, SLOs/SLEs, and network resource partitions.

Recent reviews and discussions of draft-bestbar-teas-ns-packet have made it clear that the current text is not sufficiently unambiguous. Although I know what I meant, the text is open to interpretation and needs to be tightened up.

  *   A network slice is a service requested by / provided for the customer
  *   The network slice service is expressed in terms of one or more connectivity constructs.
An implementation or operator is free to limit the number of connectivity constructs in a slice to exactly one.
  *   Each connectivity construct has a set of SLOs and SLEs.
The set does not need to be the same for every connectivity construct in the slice.
An implementation or operator is free to require that all connectivity constructs in a slice have the same set of SLOs and SLEs.
  *   One or more connectivity constructs from one or more slices are mapped to a set of network resources called a Network Resource Partition (NRP).
One connectivity construct is only mapped to one NRP.
An NRP may be chosen because of its ability to support a specific set of SLOs and SLEs, or its ability to support particular connectivity types.
An implementation or operator is free to map each connectivity construct to a separate NRP, although there may be scaling implications depending on the solution implemented.
Thus, the connectivity constructs in one slice may be mapped to one or more NRPs.
By implication from the above, an implementation or operator is free to map all the connectivity constructs in a slice to a single NRP and to not share that NRP with connectivity constructs from another slice.
  *   An NRP is simply a collection of (reserved) resources extracted from the underlying physical network.
The process of determining the NRP may be made easier if the physical network topology is first filtered into a Filter Topology in order to be aware of the subset of network resources that are suitable for specific NRPs.

  1.  What to call an end point

During IETF-112 we spotted several overlapping terms (CE, end-point, NSE, maybe PE) and decided that the more generic term “Service Demarcation Point” should be used.

This will help remove the confusion about where the service begins and ends, allowing the existing text that enumerates the options to not get blurred by other text in the document. Of course, CEs and PEs still exist and need to be mentioned, but the service demarcation point term allows us to be generic without forcing any one of the four implementation options already described in the text and Figure 1.

  1.  General editorial pass to clean up spelling and language use

Best,

Adrian

_______________________________________________
Teas mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!WL_wI8kuRrMFYl1lCmWpDid68WjMApSOrV9w5bm6Vs98TbNAGGNGRycfgNPTLu0$

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 2 Mar 2022 14:19:47 -0800

Looks good to me!

Cheers,

Jeff

From: Adrian Farrel
Sent: Wednesday, March 2, 2022 1:15 PM
To: TEAS WG
Subject: [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

Hi,

Deprecating NBI/SBI

Clarifying the relationships between slices, connectivity constructs, SLOs/SLEs, and network resource partitions.

A network slice is a service requested by / provided for the customer

The network slice service is expressed in terms of one or more connectivity constructs.
An implementation or operator is free to limit the number of connectivity constructs in a slice to exactly one.

Each connectivity construct has a set of SLOs and SLEs.
The set does not need to be the same for every connectivity construct in the slice.
An implementation or operator is free to require that all connectivity constructs in a slice have the same set of SLOs and SLEs.

One or more connectivity constructs from one or more slices are mapped to a set of network resources called a Network Resource Partition (NRP).

An NRP is simply a collection of (reserved) resources extracted from the underlying physical network.
The process of determining the NRP may be made easier if the physical network topology is first filtered into a Filter Topology in order to be aware of the subset of network resources that are suitable for specific NRPs.

What to call an end point

General editorial pass to clean up spelling and language use

Best,

Adrian

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 2 Mar 2022 23:53:27 +0000 (UTC)

Hi Adrian,Good job!
I wonder if we need a discussion on what does it mean exactly to guarantee an SLO. Imagine that one of a NS service SLOs is not being met once in a month for 10ms. Is this acceptabl? The answer could depend on a client. For example.  IPTV client could be OK with that, while Remote Surgery application client may be not.  The tolerance to the divergence from an agreed upon SLO could be different from SLO to SLO .  So my question is would it be a good idea to couple each SLO with SLO divergence tolerance?
Thanks,Igor
Sent from Yahoo Mail on Android 
 
  On Wed, Mar 2, 2022 at 5:20 PM, Jeff Tantsura<[email-masked]> wrote:   _______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 2 Mar 2022 19:03:01 -0500

I think that is part of the difference between the SLO and the SLA.  The 
SLO is an objective.  It may have measurement windows (e.g. average 
latency variation over 1 second periods).  It is either met or failed. 
The question of how often the operator commits to meeting it 
(90%...99.999%) and what happens if he fails too much are for the SLA, 
not the SLO as I understand them.

Yours,
Joel

On 3/2/2022 6:53 PM, Igor Bryskin wrote:
> Hi Adrian,
> Good job!
> 
> I wonder if we need a discussion on what does it mean exactly to 
> guarantee an SLO. Imagine that one of a NS service SLOs is not being met 
> once in a month for 10ms. Is this acceptabl? The answer could depend on 
> a client. For example.  IPTV client could be OK with that, while Remote 
> Surgery application client may be not.  The tolerance to the divergence 
> from an agreed upon SLO could be different from SLO to SLO .  So my 
> question is would it be a good idea to couple each SLO with SLO 
> divergence tolerance?
> 
> Thanks,
> Igor
> 
> <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>
> 
>     On Wed, Mar 2, 2022 at 5:20 PM, Jeff Tantsura
>     <[email-masked]> wrote:
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/teas>
> 
>

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 3 Mar 2022 00:09:11 +0000 (UTC)

I agree, but what if the tolerance is different wrt different SLOs within the same SLA?
Igor

  On Wed, Mar 2, 2022 at 7:03 PM, Joel M. Halpern<[email-masked]> wrote:   I think that is part of the difference between the SLO and the SLA.  The 

Yours,
Joel

On 3/2/2022 6:53 PM, Igor Bryskin wrote:
> <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers⁡_wl=ym⁡_sub1=Internal⁡_sub2=Global_YGrowth⁡_sub3=EmailSignature>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 2 Mar 2022 19:11:43 -0500

The tolerances are likely to be different.  The SLA will have multiple 
terms.  I imagine (and my imagination is bad) terms of the form "for 
traffic set X, for parameter Y, the SLO is Z, and it will be met with 
confidence P, and penalty M."  Penalty might be separate with all sorts 
of complicated relationships between failures and penalties.

Yours,
Joel

On 3/2/2022 7:09 PM, Igor Bryskin wrote:
>     On Wed, Mar 2, 2022 at 7:03 PM, Joel M. Halpern
>     <[email-masked]> wrote:
>     <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers⁡_wl=ym⁡_sub1=Internal⁡_sub2=Global_YGrowth⁡_sub3=EmailSignature
>     <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>>
>      >
>      >    <[email-masked] <mailto:[email-masked]>> wrote:
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >    <https://www.ietf.org/mailman/listinfo/teas
>     <https://www.ietf.org/mailman/listinfo/teas>>
>      >
>      >

---

From: <[email-masked]>
Date: Thu, 3 Mar 2022 06:48:55 +0000

Hi Adrian, all,

All good points. Thanks for tracking the issues and fixing them.

For the third point, I wonder if it is useful to include a short statement to position the service demarcation point vs. service attachment point (draft-ietf-opsawg-sap) or leave that to the SAP spec.

Cheers,
Med

De : Teas <[email-masked]> De la part de Adrian Farrel
Envoyé : mercredi 2 mars 2022 22:15
À : 'TEAS WG' <[email-masked]>
Objet : [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

Hi,

  1.  Deprecating NBI/SBI

Per the discussion at IETF-112 and following on from Med's comments, I am replacing "NBI" with "IETF Network Slice Service Interface", and "SBI" with "Network Configuration Interface".

During IETF-112 we spotted several overlapping terms (CE, end-point, NSE, maybe PE) and decided that the more generic term "Service Demarcation Point" should be used.

Best,

Adrian

_________________________________________________________________________________________________________________________

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: <[email-masked]>
Date: Thu, 3 Mar 2022 08:22:30 +0000

Hi all, 

Agree with Joel. 

I don't think that slicing comes with specifics on how these matters are already handled in IP services. A randomly picked example can be found here: https://www.cyberlynk.net/company-information/legal/ip-transit-sla/ 

However, the slice modeling should be designed with provisions so that advanced SLAs can be built.  

For example, draft-ietf-teas-ietf-network-slice-nbi-yang includes attributes that are characterized with their max values, e.g., 

      "network-slice-slo-one-way-latency": Indicates the maximum one-way
      latency between two NSE.

      "network-slice-slo-two-way-latency": Indicates the maximum round-
      trip latency between two NSE.

I suggest to consider updating the model to manipulate percentile values, not only peak/min/avg values. 

Cheers,
Med

> -----Message d'origine-----
> De : Teas <[email-masked]> De la part de Joel M. Halpern
> Envoyé : jeudi 3 mars 2022 01:12
> À : Igor Bryskin <[email-masked]>; TEAS WG <[email-masked]>
> Objet : Re: [Teas] Upcoming changes to draft-ietf-teas-ietf-network-
> slices
> 
> > <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrow
> > th_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Glo
> > bal_YGrowth&af_sub3=EmailSignature>
> >
> >     I think that is part of the difference between the SLO and the
> SLA.
> >     The
> >      > a client. For example.  IPTV client could be OK with that,
> while
> >     Remote
> <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth
> _AndroidEmailSig__AndroidUsers⁡_wl=ym⁡_sub1=Internal⁡_sub2=Global_YGrowt
> h⁡_sub3=EmailSignature
> >
> <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth
> _AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_
> YGrowth&af_sub3=EmailSignature>>
> >      >

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 3 Mar 2022 09:16:28 -0000

OK. Useful discussion. I think that the slicing framework definition of SLA ...

   *  A Service Level Agreement (SLA) is an explicit or implicit
      contract between the customer of an IETF Network Slice service and
      the provider of the slice.  The SLA is expressed in terms of a set
      of SLOs and SLEs that are to be applied for a given connectivity
      construct between a sending SDP and the set of receiving SDPs, and
      may include commercial terms as well as any consequences for
      violating these SLOs and SLEs.

...can be extended by a view words to include "the extent to which divergence from individual SLOs and SLEs can be tolerated"

But I don't think we should go further than that in the framework. 

A

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of [email-masked]
Sent: 03 March 2022 08:23
To: Joel M. Halpern <[email-masked]>; Igor Bryskin <[email-masked]>; TEAS WG <[email-masked]>
Subject: Re: [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

Hi all, 

Agree with Joel. 

Cheers,
Med

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 3 Mar 2022 09:33:00 -0000

Hi Med,

Thanks, I missed that document (too many documents!).

Reading it, I think the very first sentence is the important one for us…

   From the perspective of a service provider, the Service Attachment

   Points (SAPs) are abstraction of the network reference points where

   network services can be delivered to customers.

So from our point of view, the SAP is the abstraction of the Service
Demarcation Point.

I can add…

   An SDP may be abstracted as a Service Attachment Point (SAP)
[I-D.ietf-opsawg-sap]

   for the purpose generalising the concept across multiple service types

   and representing it in management and configuration systems.

Or do you have better words?

Cheers,

Adrian

From: [email-masked] <[email-masked]> 
Sent: 03 March 2022 06:49
To: [email-masked]; 'TEAS WG' <[email-masked]>
Subject: RE: [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

Hi Adrian, all,

For the third point, I wonder if it is useful to include a short statement
to position the service demarcation point vs. service attachment point
(draft-ietf-opsawg-sap) or leave that to the SAP spec. 

Cheers,

Med

De : Teas <[email-masked] <mailto:[email-masked]> > De la part
de Adrian Farrel
Envoyé : mercredi 2 mars 2022 22:15
À : 'TEAS WG' <[email-masked] <mailto:[email-masked]> >
Objet : [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

Hi,

1.	Deprecating NBI/SBI

Per the discussion at IETF-112 and following on from Med’s comments, I am
replacing “NBI” with “IETF Network Slice Service Interface”, and “SBI” with
“Network Configuration Interface”. 

During IETF-112 we spotted several overlapping terms (CE, end-point, NSE,
maybe PE) and decided that the more generic term “Service Demarcation Point”
should be used.

Best,

Adrian

____________________________________________________________________________
_____________________________________________
 
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: <[email-masked]>
Date: Thu, 3 Mar 2022 12:35:36 +0000

Re-,

Looks good to me. Thanks.

Cheers,
Med

De : Adrian Farrel <[email-masked]>
Envoyé : jeudi 3 mars 2022 10:33
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; 'TEAS WG' <[email-masked]>
Objet : RE: [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

Hi Med,

Reading it, I think the very first sentence is the important one for us...

So from our point of view, the SAP is the abstraction of the Service Demarcation Point.

I can add...

   An SDP may be abstracted as a Service Attachment Point (SAP) [I-D.ietf-opsawg-sap]
   for the purpose generalising the concept across multiple service types
   and representing it in management and configuration systems.

Cheers,
Adrian

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: 03 March 2022 06:49
To: [email-masked]<mailto:[email-masked]>; 'TEAS WG' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

Hi Adrian, all,

Cheers,
Med

De : Teas <[email-masked]<mailto:[email-masked]>> De la part de Adrian Farrel
Envoyé : mercredi 2 mars 2022 22:15
À : 'TEAS WG' <[email-masked]<mailto:[email-masked]>>
Objet : [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

Hi,

  1.  Deprecating NBI/SBI

Best,

Adrian

Thank you.

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Fri, 4 Mar 2022 04:08:13 +0000

Hi All,

Interesting discussion.

FYI, 3GPP defines slice SLOs as ServiceProfile in TS28.541 Clause 6.3.3[1], which basically refers GSMA GST, NG.116[2].
Both specifications define "availability".

NG.116 Clause 3.4.1 Availability
(Communication service) availability: percentage value of the amount of time the end-to-end communication service is delivered according to an agreed QoS, divided by the amount of time the system is expected to deliver the end-to-end service according to the specification in a specific area, see also 3GPP TS 22.261 [27].

We understand that this means the confidence which satisfies *all* (other) SLOs, e.g. throughput, latency, etc..., and should be negotiated with the customer as SLA.
So, we believe any one of SLOs violates the value against "availability", then that falls to penalty.

Mission critical usecases like factory automation or AVG control may not fit percentile SLO, since there may be a strict requirement, e.g. maximum latency or deterministicy, for the application to properly work.

[1]https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3400
[2]https://www.gsma.com/newsroom/wp-content/uploads//NG.116-v5.0-7.pdf

All the best,
Kenichi

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Teas <[email-masked]> on behalf of Adrian Farrel <[email-masked]>
Sent: Thursday, March 3, 2022 6:17 PM
To: [email-masked]; 'Joel M. Halpern'; 'Igor Bryskin'; 'TEAS WG'
Subject: Re: [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

A

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of [email-masked]
Sent: 03 March 2022 08:23
To: Joel M. Halpern <[email-masked]>; Igor Bryskin <[email-masked]>; TEAS WG <[email-masked]>
Subject: Re: [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

Hi all,

Agree with Joel.

Cheers,
Med

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 3 Mar 2022 23:28:48 -0500

The approach I described supports the case you describe (one 
availability for all parameters), but allows us to recognize that not 
all cases will want that.

Yours,
Joel

On 3/3/2022 11:08 PM, Ogaki, Kenichi wrote:
> Hi All,
> 
> Interesting discussion.
> 
> FYI, 3GPP defines slice SLOs as ServiceProfile in TS28.541 Clause 
> 6.3.3[1], which basically refers GSMA GST, NG.116[2].
> (Communication service) availability: percentage value of the amount of 
> time the end-to-end communication service is delivered according to an 
> agreed QoS, divided by the amount of time the system is expected to 
> deliver the end-to-end service according to the specification in a 
> specific area, see also 3GPP TS 22.261 [27].
> 
> We understand that this means the confidence which satisfies *all* 
> (other) SLOs, e.g. throughput, latency, etc..., and should be negotiated 
> with the customer as SLA.
> So, we believe any one of SLOs violates the value against 
> "availability", then that falls to penalty.
> 
> Mission critical usecases like factory automation or AVG control may not 
> fit percentile SLO, since there may be a strict requirement, e.g. 
> maximum latency or deterministicy, for the application to properly work.
> 
> Get Outlook for iOS <https://aka.ms/o0ukef>
> ------------------------------------------------------------------------
> *From:* Teas <[email-masked]> on behalf of Adrian Farrel 
> <[email-masked]>
> *Sent:* Thursday, March 3, 2022 6:17 PM
> *To:* [email-masked]; 'Joel M. Halpern'; 'Igor Bryskin'; 
> 'TEAS WG'
> *Subject:* Re: [Teas] Upcoming changes to 
> draft-ietf-teas-ietf-network-slices
> ...can be extended by a view words to include "the extent to which 
> divergence from individual SLOs and SLEs can be tolerated"
> 
> To: Joel M. Halpern <[email-masked]>; Igor Bryskin 
> <[email-masked]>; TEAS WG <[email-masked]>
> I don't think that slicing comes with specifics on how these matters are 
> already handled in IP services. A randomly picked example can be found 
> here: 
> https://www.cyberlynk.net/company-information/legal/ip-transit-sla/ 
> <https://www.cyberlynk.net/company-information/legal/ip-transit-sla/>
> 
> For example, draft-ietf-teas-ietf-network-slice-nbi-yang includes 
> attributes that are characterized with their max values, e.g.,
> 
>> >      > Hi Adrian,
>> >      > Good job!
>> >      >
>> >      > I wonder if we need a discussion on what does it mean exactly
>> to
>> >      > guarantee an SLO. Imagine that one of a NS service SLOs is not
>> >     being met
>> >      > once in a month for 10ms. Is this acceptabl? The answer could
>> >     depend on
>> >      > a client. For example.  IPTV client could be OK with that,
>> while
>> >     Remote
>> >      > Surgery application client may be not.  The tolerance to the
>> >     divergence
>> >      > from an agreed upon SLO could be different from SLO to SLO
>> .  So my
>> >      > question is would it be a good idea to couple each SLO with SLO
>> >      > divergence tolerance?
>> >      >
>> >      > Thanks,
>> >      > Igor
>> >      >
>> >      > Sent from Yahoo Mail on Android
>> >      >
>> >
>> >      >
>> >      >    On Wed, Mar 2, 2022 at 5:20 PM, Jeff Tantsura
>> >      >    <[email-masked] <mailto:[email-masked] <mailto:[email-masked]>>>
>> wrote:
>> >      >    _______________________________________________
>> >      >    Teas mailing list
>> >      > [email-masked] <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked]
>> >     <mailto:[email-masked] <mailto:[email-masked]>>>
>> >      > https://www.ietf.org/mailman/listinfo/teas 
>> >      >    <https://www.ietf.org/mailman/listinfo/teas
> <https://www.ietf.org/mailman/listinfo/teas>>>
>> >      >
>> >      >
>> >      > _______________________________________________
>> >      > Teas mailing list
>> >      > [email-masked] <mailto:[email-masked] <mailto:[email-masked]>>
>> >      > https://www.ietf.org/mailman/listinfo/teas 
>> >     [email-masked] <mailto:[email-masked] <mailto:[email-masked]>>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
> recu ce message par erreur, veuillez le signaler

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 4 Mar 2022 14:43:33 +0000 (UTC)

Joel,
Your approach implies that things like Tolerance, Divergence, Conviction could be defined outside/independent of referred SLOs. Are you sure it will be always the case or  could it be  cases where said things would have to be defined in SLO specific terms?
Don't you think that what is discussed here applies to SLEs as much as to SLOs?
And back to my original question - shouldn't your's or/and alternative approaches be reflected  in some way or other in the framework  document?
Cheers,Igor

  On Thu, Mar 3, 2022 at 11:29 PM, Joel M. Halpern<[email-masked]> wrote:   The approach I described supports the case you describe (one 
availability for all parameters), but allows us to recognize that not 
all cases will want that.

Yours,
Joel

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 4 Mar 2022 19:14:24 -0000

Hi Igor,

> And back to my original question - shouldn't your's or/and alternative

> approaches be reflected  in some way or other in the framework

> document?

I’m (of course, as editor) open to suggestions of text. Slightly less open to suggestions that I should write something, myself. 

But before you invest, I don’t think that we want to open up a the framework to include an information model. This is a fine line, I admit. Some structural things will guide an information model (or straight into the data model) and *are* included in the framework. Other things, however, are getting into finer details and don’t belong. 

If we find we have too much “stuff” we should definitely split out into a separate information model document, or just sit down with the authors of the service model draft and make sure they have it covered. We certainly don’t need to use the framework draft as a way of talking to the authors of the YANG model!

Cheers,

Adrian

From: Teas <[email-masked]> On Behalf Of Igor Bryskin
Sent: 04 March 2022 14:44
To: [email-masked]; Joel M. Halpern <[email-masked]>; Ogaki, Kenichi <[email-masked]>; 'TEAS WG' <[email-masked]>
Subject: Re: [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

Joel,

Cheers,

Igor

Sent from Yahoo Mail on Android <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature> 

On Thu, Mar 3, 2022 at 11:29 PM, Joel M. Halpern

Yours,
Joel

On 3/3/2022 11:08 PM, Ogaki, Kenichi wrote:
> [2]https://www.gsma.com/newsroom/wp-content/uploads//NG.116-v5.0-7.pdf <https://www.gsma.com/newsroom/wp-content/uploads/NG.116-v5.0-7.pdf> 
> 
> All the best,
> Kenichi
> 
> *From:* Teas <[email-masked] <mailto:[email-masked]> > on behalf of Adrian Farrel 
> <[email-masked] <mailto:[email-masked]> >
> *To:* [email-masked] <mailto:[email-masked]> ; 'Joel M. Halpern'; 'Igor Bryskin'; 
> 'TEAS WG'
> From: Teas <[email-masked] <mailto:[email-masked]> > On Behalf Of [email-masked] <mailto:[email-masked]> 
> To: Joel M. Halpern <[email-masked] <mailto:[email-masked]> >; Igor Bryskin 
> <[email-masked] <mailto:[email-masked]> >; TEAS WG <[email-masked] <mailto:[email-masked]> >
> https://www.cyberlynk.net/company-information/legal/ip-transit-sla/  <https://www.cyberlynk.net/company-information/legal/ip-transit-sla/%20> 
>> De : Teas <[email-masked] <mailto:[email-masked]> > De la part de Joel M. Halpern
>> À : Igor Bryskin <[email-masked] <mailto:[email-masked]> >; TEAS WG <[email-masked] <mailto:[email-masked]> >
>> > <https://go.onelink.me/107872968?pid=InProduct <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrow> &c=Global_Internal_YGrow
>> >     <[email-masked] <mailto:[email-masked]> > wrote:
>> <https://go.onelink.me/107872968?pid=InProduct <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth> &c=Global_Internal_YGrowth
>> <https://go.onelink.me/107872968?pid=InProduct <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth> &c=Global_Internal_YGrowth
>> >      >    <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>>
>> wrote:
>> >      > [email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >> <mailto:[email-masked] <mailto:[email-masked]> 
>> >     <mailto:[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>>
>> >      > https://www.ietf.org/mailman/listinfo/teas  <https://www.ietf.org/mailman/listinfo/teas%20> 
>> >     <https://www.ietf.org/mailman/listinfo/teas  <https://www.ietf.org/mailman/listinfo/teas%20> 
>> >     <https://www.ietf.org/mailman/listinfo/teas  <https://www.ietf.org/mailman/listinfo/teas%20> 
>> >      > [email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>
>> >      > https://www.ietf.org/mailman/listinfo/teas  <https://www.ietf.org/mailman/listinfo/teas%20> 
>> >     <https://www.ietf.org/mailman/listinfo/teas  <https://www.ietf.org/mailman/listinfo/teas%20> 
>> >     [email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>
>> >    https://www.ietf.org/mailman/listinfo/teas  <https://www.ietf.org/mailman/listinfo/teas%20> 
>> >     <https://www.ietf.org/mailman/listinfo/teas  <https://www.ietf.org/mailman/listinfo/teas%20> 
>> https://www.ietf.org/mailman/listinfo/teas  <https://www.ietf.org/mailman/listinfo/teas%20> 

> https://www.ietf.org/mailman/listinfo/teas  <https://www.ietf.org/mailman/listinfo/teas%20> 
> https://www.ietf.org/mailman/listinfo/teas  <https://www.ietf.org/mailman/listinfo/teas%20>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 4 Mar 2022 15:02:52 -0500

Am I sure?  No.  I am reasonably confident that keeping the contractual 
aspects separate from the SLO will help, and cover the cases?  Yes.

One can construct an argument that when not everything can be met the 
decision process needs more data to decide what to meet and what to give 
up on.  Following that to the extreme, the full specification of 
penalties, importance of customer happiness, and every other business 
factor would end up in the SLO.  I do not think that is good for us.

Yours,
Joel

On 3/4/2022 9:43 AM, Igor Bryskin wrote:
> Joel,
> 
> Your approach implies that things like Tolerance, Divergence, Conviction 
> could be defined outside/independent of referred SLOs. Are you sure it 
> will be always the case or  could it be  cases where said things would 
> have to be defined in SLO specific terms?
> 
> approaches be reflected  in some way or other in the framework  document?
> 
> Cheers,
> Igor
> 
>     <https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3400>
>      >
>     <https://www.gsma.com/newsroom/wp-content/uploads//NG.116-v5.0-7.pdf>
>      >
>      > All the best,
>      > Kenichi
>      >
>      > Get Outlook for iOS <https://aka.ms/o0ukef <https://aka.ms/o0ukef>>
>      >
>      > *From:* Teas <[email-masked]
>     <mailto:[email-masked]>> on behalf of Adrian Farrel
>      > <[email-masked] <mailto:[email-masked]>>
>      > *To:* [email-masked]
>     <mailto:[email-masked]>; 'Joel M. Halpern'; 'Igor
>     Bryskin';
>      > 'TEAS WG'
>      > OK. Useful discussion. I think that the slicing framework
>     definition of
>      > SLA ...
>      >
>      > From: Teas <[email-masked] <mailto:[email-masked]>>
>     On Behalf Of [email-masked]
>     <mailto:[email-masked]>
>      > To: Joel M. Halpern <[email-masked]
>     <mailto:[email-masked]>>; Igor Bryskin
>      > <[email-masked] <mailto:[email-masked]>>; TEAS WG
>     <[email-masked] <mailto:[email-masked]>>
>     <https://www.cyberlynk.net/company-information/legal/ip-transit-sla/ >
>      >
>     <https://www.cyberlynk.net/company-information/legal/ip-transit-sla/
>     <https://www.cyberlynk.net/company-information/legal/ip-transit-sla/>>
>      >
>      > However, the slice modeling should be designed with provisions so
>     that
>      > advanced SLAs can be built.
>      >
>      >> De : Teas <[email-masked] <mailto:[email-masked]>>
>     De la part de Joel M. Halpern
>      >> À : Igor Bryskin <[email-masked]
>     <mailto:[email-masked]>>; TEAS WG <[email-masked]
>     <mailto:[email-masked]>>
>     <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrow>
>      >> >
>      >> >     <[email-masked] <mailto:[email-masked]>> wrote:
>      >> >     (90%...99.999%) and what happens if he fails too much are
>     for the
>      >> SLA,
>     <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth>
>      >>
>     <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth>
>      >>
>      >> >      >    <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>>
>      >> wrote:
>      >> >      > [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>> <mailto:[email-masked] <mailto:[email-masked]>
>      >> >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>
>     <https://www.ietf.org/mailman/listinfo/teas >
>     <https://www.ietf.org/mailman/listinfo/teas >
>     <https://www.ietf.org/mailman/listinfo/teas >
>     <https://www.ietf.org/mailman/listinfo/teas>>>>
>      >> >      >
>      >> >      >
>      >> >      > [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>     <https://www.ietf.org/mailman/listinfo/teas >
>     <https://www.ietf.org/mailman/listinfo/teas >
>     <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>     <https://www.ietf.org/mailman/listinfo/teas >
>     <https://www.ietf.org/mailman/listinfo/teas >
>     <https://www.ietf.org/mailman/listinfo/teas >
>      > Orange decline toute responsabilite si ce message a ete altere,
>     deforme
>      > ou falsifie. Merci.
>      >
>      > As emails may be altered, Orange is not liable for messages that
>     have
>      > been modified, changed or falsified.
>      > Thank you.
> 
>      >
>     <https://www.ietf.org/mailman/listinfo/teas >
>     <https://www.ietf.org/mailman/listinfo/teas >

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 4 Mar 2022 13:54:16 -0800

Hi Med, et al.,
thank you for pointing out the example of using the maximum value of a
performance metric as the measure of service conformance to an SLO. I think
that other statistical parameters, e.g., percentile, may be also used in
that role.
And as we're discussing the topic of IETF network slice conformance to an
SLA that is presented as a multi-SLO set, I bring to your attention a new
draft submitted to the IPPM WG - Precision Availability Metrics for
SLO-Governed End-to-End Services
<https://datatracker.ietf.org/doc/draft-mhmcsfh-ippm-pam/> . We always
appreciate your comments, questions, and suggestions. Please consider
adding the IPPM mailing list.

Regards,
Greg

On Wed, Mar 2, 2022 at 10:49 PM <[email-masked]> wrote:

> *De :* Teas <[email-masked]> *De la part de* Adrian Farrel
> *Envoyé :* mercredi 2 mars 2022 22:15
> *À :* 'TEAS WG' <[email-masked]>
> *Objet :* [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices
>
>
>
> Hi,
>
>
>
>    1. Clarifying the relationships between slices, connectivity
> Recent reviews and discussions of draft-bestbar-teas-ns-packet have made
> it clear that the current text is not sufficiently unambiguous. Although I
> know what I meant, the text is open to interpretation and needs to be
> tightened up.
>
>
>
>    - A network slice is a service requested by / provided for the customer
>    - The network slice service is expressed in terms of one or more
>    connectivity constructs.
>    An implementation or operator is free to limit the number of
>    connectivity constructs in a slice to exactly one.
>    - Each connectivity construct has a set of SLOs and SLEs.
>    - One or more connectivity constructs from one or more slices are
>    An NRP may be chosen because of its ability to support a specific set
>    of SLOs and SLEs, or its ability to support particular connectivity types.
>    An implementation or operator is free to map each connectivity
>    construct to a separate NRP, although there may be scaling implications
>    depending on the solution implemented.
>    By implication from the above, an implementation or operator is free
>    to map all the connectivity constructs in a slice to a single NRP and to
>    not share that NRP with connectivity constructs from another slice.
>    - An NRP is simply a collection of (reserved) resources extracted from
> maybe PE) and decided that the more generic term “Service Demarcation
> Point” should be used.
>
>
>
> This will help remove the confusion about where the service begins and
> ends, allowing the existing text that enumerates the options to not get
> blurred by other text in the document. Of course, CEs and PEs still exist
> and need to be mentioned, but the service demarcation point term allows us
> to be generic without forcing any one of the four implementation options
> already described in the text and Figure 1.
>
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 4 Mar 2022 17:41:11 -0500

Hi Adrian

Excellent  summarization !

Kind Regards

Gyan

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 4 Mar 2022 18:43:11 -0500

Hi Kenichi / All

Good point to bring up the 3GPP standards and development related to
Network slicing within 3GPP.

As TEAS WG is defining the framework for Network Slicing, how is parity
maintained between two different SDOs, IETF and 3GPP on this common topic
 of Network Slicing?

I know we have other development areas such as optical for example where we
have overlap between SDOs.

I believe we do have an IETF to 3GPP liaison related to 3GPP development to
keep abreast on developments works on either SDO.  But I wonder if let’s
say our TEAS Network Slicing development work is being communicated to the
3GPP developers.

As 3GPP 5G would be the major consumer of network slicing,  how do we keep
the development synchronized as well not be divergent and contradictory.

Worst would be if the work we are doing here is done in vain if the work is
not being incorporated into the 3GPP standards.

Kind Regards

Gyan

On Thu, Mar 3, 2022 at 11:18 PM Ogaki, Kenichi <[email-masked]> wrote:

> agreed QoS, divided by the amount of time the system is expected to deliver
> the end-to-end service according to the specification in a specific area,
> see also 3GPP TS 22.261 [27].
>
> We understand that this means the confidence which satisfies *all* (other)
> SLOs, e.g. throughput, latency, etc..., and should be negotiated with the
> customer as SLA.
> fit percentile SLO, since there may be a strict requirement, e.g. maximum
> latency or deterministicy, for the application to properly work.
>
> [1]
> https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3400
> ------------------------------
> *From:* Teas <[email-masked]> on behalf of Adrian Farrel <
> [email-masked]>
> To: Joel M. Halpern <[email-masked]>; Igor Bryskin <
> [email-masked]>; TEAS WG <[email-masked]>
> here: https://www.cyberlynk.net/company-information/legal/ip-transit-sla/
>
> > >      >    <[email-masked] <mailto:[email-masked]
> <[email-masked]>>>
> > wrote:
> > >      > [email-masked] <mailto:[email-masked] <[email-masked]>> <mailto:
> [email-masked]
> > >     <mailto:[email-masked] <[email-masked]>>>
> > >      > [email-masked] <mailto:[email-masked] <[email-masked]>>
> > >     [email-masked] <mailto:[email-masked] <[email-masked]>>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 5 Mar 2022 09:41:37 -0000

Hi all,

[Copying Gonzalo, the IETF’s liaison manager for the 3GPP relationship]

I am not convinced that 5G will be *the* major consumer of IETF network slicing. But it is potentially *a* major consumer, so clearly our work must be good enough to support the 3GPP requirements.

There are several points at which we need to check that we are not breaking what the 3GPP want to do.

*	Is the framework general enough?
*	Does the work on “mapping 3GPP slices to IETF slices” provide enough information?
*	Do the YANG models allow adequate configuration and reporting?

I would suggest that the chairs might want to arrange for a liaison statement to the 3GPP to say:

*	The framework is close to complete, and now would be an ideal time to do a review
*	Other work is progressing at the working group (point at some drafts), and that input is always welcome
*	The most effective way to contribute to and steer the work is by direct input from individuals via the mailing list

Of course, those of you active in 3GPP or with friends who are, can make this go smoother by simply arranging for the reviews and input.

Cheers,

Adrian

From: Gyan Mishra <[email-masked]> 
Sent: 04 March 2022 23:43
To: Ogaki, Kenichi <[email-masked]>
Cc: Igor Bryskin <[email-masked]>; Joel M. Halpern <[email-masked]>; TEAS WG <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

Hi Kenichi / All 

Good point to bring up the 3GPP standards and development related to Network slicing within 3GPP.

As TEAS WG is defining the framework for Network Slicing, how is parity maintained between two different SDOs, IETF and 3GPP on this common topic  of Network Slicing?

I know we have other development areas such as optical for example where we have overlap between SDOs.   

I believe we do have an IETF to 3GPP liaison related to 3GPP development to keep abreast on developments works on either SDO.  But I wonder if let’s say our TEAS Network Slicing development work is being communicated to the 3GPP developers.  

As 3GPP 5G would be the major consumer of network slicing,  how do we keep the development synchronized as well not be divergent and contradictory.

Worst would be if the work we are doing here is done in vain if the work is not being incorporated into the 3GPP standards.

Kind Regards 

Gyan

On Thu, Mar 3, 2022 at 11:18 PM Ogaki, Kenichi <[email-masked] <mailto:[email-masked]> > wrote:

Hi All,

Interesting discussion.

All the best,

Kenichi

  _____  

From: Teas <[email-masked] <mailto:[email-masked]> > on behalf of Adrian Farrel <[email-masked] <mailto:[email-masked]> >
Sent: Thursday, March 3, 2022 6:17 PM
To: [email-masked] <mailto:[email-masked]> ; 'Joel M. Halpern'; 'Igor Bryskin'; 'TEAS WG'

A

-----Original Message-----
From: Teas <[email-masked] <mailto:[email-masked]> > On Behalf Of [email-masked] <mailto:[email-masked]> 
Sent: 03 March 2022 08:23
To: Joel M. Halpern <[email-masked] <mailto:[email-masked]> >; Igor Bryskin <[email-masked] <mailto:[email-masked]> >; TEAS WG <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

Hi all, 

Agree with Joel. 

Cheers,
Med

> >      >    <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked]>>
> wrote:
> >      > [email-masked] <mailto:[email-masked]>  <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]> 
> >     <mailto:[email-masked]>>
> >      > [email-masked] <mailto:[email-masked]>  <mailto:[email-masked]>
> >     [email-masked] <mailto:[email-masked]>  <mailto:[email-masked]>

-- 

Gyan Mishra

Network Solutions Architect 

Email [email-masked]

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 5 Mar 2022 23:40:47 -0500

Hi Adrian

As this is an interesting topic here are some thoughts for the framework
draft, talking to the important point that you make that IETF Network Slice
may have not just been for 5G but many use cases and from below I think pre
existing use cases.

So I would like to elaborate as I agree with you.

So basic concept of virtualization of a physical infrastructure started
decades ago with the concept of a VLAN ( Virtual LAN) and then transport
layer virtualization with ATM and Frame Relay concept of a LIS (Logical IP
Subnet) followed by MPLS/IP VPN RFC 4364 which gave us a virtualization of
the physical infrastructure traditional single customer  global table
routing to VPN overlay multi tenancy capabilities.  So RFC 4364 gave us the
ability to slice up the physical infrastructure allowing for multi tenancy
overlay virtualization.  RSVP-TE gave us the ability to steer traffic and
VPN to TE mapping basically providing a VPN overlay slice to be underpinned
to a discrete TE underlay path.  ACTN has further extended that capability
providing an abstraction TE controls into a Type 1 and 2 VN Network Slice.

I believe the concept of network slicing and VPN overlay underpinning to a
discrete underlay has been further extended with Segment Routing and SR-TE
capabilities to extend past VRF to RSVP-TE mapping to micro and macro flow
path steering moving the VPN overlay to underlay underpinning capabilities
of “network slicing” further along.

So the framework draft does mention in section 1.1 below ..

“ Driven largely by needs surfacing from 5G, the concept of network slicing
has gained traction ([NGMN-NS-Concept
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-07#ref-NGMN-NS-Concept>],
[TS23501
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-07#ref-TS23501>],
and [TS28530
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-07#ref-TS28530>
]).”

So the IETF network slice is a network slice that describes Technologies
standardized by the IETF to narrow the scope.

So in reality the concept of “network slicing” has been around  for
decades.

A key ingredient to IETF network slicing is RFC 4364 MPLS/IP VPN overlay
virtualization layer which has been around for decades used ubiquitously by
operators worldwide.

The framework of an IETF network slice and connectivity matrix is based on
the use of MPLS/IP VPN least common denominator overlay virtualization that
has existed for decades.

So now coming back full circle, which came first chicken or the egg - “5G
driving network slicing” or has has network slicing been a pre existing
condition that we are now fine tuning with discrete underlay resource
provisioning to accommodate 5G Network slicing being in-line with those 5G
 requirements, and then can as well to your point continue on with all the
pre existing condition use cases for network slicing that exists but now
being able to provide “IETF Network Slice” parity that has been developed
to be in sync with 5G network slicing requirements for operators, but now
also being able to reuse the IETF Network Slice for all pre existing
conditions of network slicing that have existed well before 5G came along.

Another thought is that IETF network slice is Technology agnostic, however
as there are requirements for each technology such as for example 3GPP,
thus parity must be maintained.  So it’s like Technology agnostic with a
caveat of dependence on the technology as far as parity as we see with 3GPP
SDO.

Many Thanks

Gyan

On Fri, Mar 4, 2022 at 6:43 PM Gyan Mishra <[email-masked]> wrote:

> I believe we do have an IETF to 3GPP liaison related to 3GPP development
> to keep abreast on developments works on either SDO.  But I wonder if let’s
> Worst would be if the work we are doing here is done in vain if the work
> is not being incorporated into the 3GPP standards.
>
> Kind Regards
>
> Gyan
>
>> > > <
>> https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrow
>> > <
>> https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth
>> > <
>> https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth

*Gyan Mishra*

*M 301 502-1347*

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Sun, 6 Mar 2022 10:06:30 +0000

Hi all,

Just for you to know, I’m working on a draft on the mapping of 3GPP slices to IETF network slices, which I will upload before cutoff with the idea of being presented at IETF113. A complementary view, as well, on functionalities to be satisfied by IETF Network Slices to support different slice consumers can be found in draft-ietf-teas-ietf-network-slices, which is also in process to be updated for IETF113.

Bets regards

Luis

De: Adrian Farrel <[email-masked]>
Enviado el: sábado, 5 de marzo de 2022 10:42
Para: 'Gyan Mishra' <[email-masked]>; 'Ogaki, Kenichi' <[email-masked]>
CC: 'TEAS WG' <[email-masked]>; 'TEAS WG Chairs' <[email-masked]>; [email-masked]
Asunto: RE: [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

Hi all,

There are several points at which we need to check that we are not breaking what the 3GPP want to do.
-          Is the framework general enough?
-          Does the work on “mapping 3GPP slices to IETF slices” provide enough information?
-          Do the YANG models allow adequate configuration and reporting?

I would suggest that the chairs might want to arrange for a liaison statement to the 3GPP to say:
-          The framework is close to complete, and now would be an ideal time to do a review
-          Other work is progressing at the working group (point at some drafts), and that input is always welcome
-          The most effective way to contribute to and steer the work is by direct input from individuals via the mailing list

Cheers,
Adrian

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Sent: 04 March 2022 23:43
To: Ogaki, Kenichi <[email-masked]<mailto:[email-masked]>>
Cc: Igor Bryskin <[email-masked]<mailto:[email-masked]>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

Hi Kenichi / All

Kind Regards

Gyan

On Thu, Mar 3, 2022 at 11:18 PM Ogaki, Kenichi <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

Interesting discussion.

[1]https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3400
[2]https://www.gsma.com/newsroom/wp-content/uploads//NG.116-v5.0-7.pdf<https://www.gsma.com/newsroom/wp-content/uploads/NG.116-v5.0-7.pdf>

All the best,
Kenichi

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Teas <[email-masked]<mailto:[email-masked]>> on behalf of Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, March 3, 2022 6:17 PM
To: [email-masked]<mailto:[email-masked]>; 'Joel M. Halpern'; 'Igor Bryskin'; 'TEAS WG'

A

-----Original Message-----
From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 03 March 2022 08:23
To: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; Igor Bryskin <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

Hi all,

Agree with Joel.

Cheers,
Med

> De : Teas <[email-masked]<mailto:[email-masked]>> De la part de Joel M. Halpern
> À : Igor Bryskin <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>
> >     <[email-masked]<mailto:[email-masked]>> wrote:
> >      >    <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
> wrote:
> >      > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>
> >     <mailto:[email-masked]>>
> >      > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
> >     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas

_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas
--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 6 Mar 2022 10:39:00 -0000

Hi Gyan,

I think you’re right that some of the foundational concepts have been around for a while.

Possibly the difference with slicing is the level of SLOs that are being offered, and the granularity of connectivity constructs within the service.

The first of these takes us a step beyond VPNs to enhanced VPNs, but the second takes us into “bundled” services.

The language about slicing being driven by 5G is inherited text. I am concerned that it comes close to “marketing hype”, but on the other hand it is trye that the concept (and name) of network slicing has received a huge boost as a result of the discussion of 5G.

Having reread your email, however, I don’t see a specific request for a change to the document.

Best,

Adrian

Sent: 06 March 2022 04:41

Hi Adrian 

As this is an interesting topic here are some thoughts for the framework draft, talking to the important point that you make that IETF Network Slice may have not just been for 5G but many use cases and from below I think pre existing use cases.

So basic concept of virtualization of a physical infrastructure started decades ago with the concept of a VLAN ( Virtual LAN) and then transport layer virtualization with ATM and Frame Relay concept of a LIS (Logical IP Subnet) followed by MPLS/IP VPN RFC 4364 which gave us a virtualization of the physical infrastructure traditional single customer  global table routing to VPN overlay multi tenancy capabilities.  So RFC 4364 gave us the ability to slice up the physical infrastructure allowing for multi tenancy overlay virtualization.  RSVP-TE gave us the ability to steer traffic and VPN to TE mapping basically providing a VPN overlay slice to be underpinned to a discrete TE underlay path.  ACTN has further extended that capability providing an abstraction TE controls into a Type 1 and 2 VN Network Slice.

I believe the concept of network slicing and VPN overlay underpinning to a discrete underlay has been further extended with Segment Routing and SR-TE capabilities to extend past VRF to RSVP-TE mapping to micro and macro flow path steering moving the VPN overlay to underlay underpinning capabilities of “network slicing” further along.

“ Driven largely by needs surfacing from 5G, the concept of network slicing has gained traction ([ <https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-07#ref-NGMN-NS-Concept> NGMN-NS-Concept], [ <https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-07#ref-TS23501> TS23501], and [ <https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-07#ref-TS28530> TS28530]).”

So the IETF network slice is a network slice that describes Technologies standardized by the IETF to narrow the scope.  

So in reality the concept of “network slicing” has been around  for decades. 

A key ingredient to IETF network slicing is RFC 4364 MPLS/IP VPN overlay virtualization layer which has been around for decades used ubiquitously by operators worldwide.  

The framework of an IETF network slice and connectivity matrix is based on the use of MPLS/IP VPN least common denominator overlay virtualization that has existed for decades.

So now coming back full circle, which came first chicken or the egg - “5G driving network slicing” or has has network slicing been a pre existing condition that we are now fine tuning with discrete underlay resource provisioning to accommodate 5G Network slicing being in-line with those 5G  requirements, and then can as well to your point continue on with all the pre existing condition use cases for network slicing that exists but now being able to provide “IETF Network Slice” parity that has been developed to be in sync with 5G network slicing requirements for operators, but now also being able to reuse the IETF Network Slice for all pre existing conditions of network slicing that have existed well before 5G came along.  

Another thought is that IETF network slice is Technology agnostic, however as there are requirements for each technology such as for example 3GPP, thus parity must be maintained.  So it’s like Technology agnostic with a caveat of dependence on the technology as far as parity as we see with 3GPP SDO.

Many Thanks 

Gyan

On Fri, Mar 4, 2022 at 6:43 PM Gyan Mishra <[email-masked] <mailto:[email-masked]> > wrote:

Hi Kenichi / All 

Kind Regards 

Gyan

Hi All,

Interesting discussion.

All the best,

Kenichi

  _____  

A

-----Original Message-----
From: Teas <[email-masked] <mailto:[email-masked]> > On Behalf Of [email-masked] <mailto:[email-masked]> 
Sent: 03 March 2022 08:23
To: Joel M. Halpern <[email-masked] <mailto:[email-masked]> >; Igor Bryskin <[email-masked] <mailto:[email-masked]> >; TEAS WG <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

Hi all, 

Agree with Joel. 

Cheers,
Med

-- 

Gyan Mishra

Email [email-masked] <mailto:[email-masked]> 

M 301 502-1347

-- 

Gyan Mishra

Email [email-masked] <mailto:[email-masked]> 

M 301 502-1347

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Sun, 6 Mar 2022 10:56:28 +0000

*************************************************************
All attached files have been encrypted for security purposes.
The password will be sent to you shortly in a separate email.

KDDIメールシステムから添付ファイル暗号化のお知らせ
弊社では情報セキュリティを強化する為、メール添付ファイル自動
暗号化システムを導入しております。パスワードは別途、お知らせ
申し上げます。ご面倒をおかけいたしますが、ご理解賜りますよう
お願いいたします。                              KDDIグループ
*************************************************************

Hi Adrian/Gyan/Luis and all,

Thanks for your comments.

I basically agree with Adrian's opinion.

See comments[KO] inline, please.

Thanks,
Kenichi

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Adrian Farrel <[email-masked]>
Sent: Saturday, March 5, 2022 6:42 PM
To: 'Gyan Mishra'; 大垣 健一
Cc: 'TEAS WG'; 'TEAS WG Chairs'; [email-masked]
Subject: RE: [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

Hi all,

[KO] Agree.

[KO] From the above points, we can only provide the framework draft for now. A mapping draft, e.g. draft-geng-teas-network-slice-mapping or Luis’s, is individual and not matured. If you say draft-ietf-teas-ietf-network-slice-nbi-yang as the YANG model, it's also not matured.

In my understanding, the transport part of 3GPP network slice is not continuously discussed in 3GPP in terms of architecture, then they may not be able to be aware of what's the lack of IETF network slice if we only send the framework draft.
In that sense, a mapping, gap analysis/applicability, draft should be a necessary piece.

As for 3GPP network slice specification, I sometimes made comments to discussion threads about framework draft to avoid the inconsistency with other SDOs' work, especially 3GPP, as possible.
I believe the current IETF network slice architecture is a superset of 3GPP network slice's one in terms of SLO, so not pessimistic.

https://mailarchive.ietf.org/arch/msg/teas/u_0C1AlEjQaBZse7I6Y0hDr5QBE/
https://mailarchive.ietf.org/arch/msg/teas/oU1b6qYIc7jDn-B-4vHAV0OrN68/
https://mailarchive.ietf.org/arch/msg/teas/wE0w5zuFOVEeR4TPVYI_mv-NGMg/

IMHO, a gap analysis is helpful, at first, based on their slice information model, TS28.541 Clause 6, which includes their slice related element relationship, SLO definition(ServiceProfile), transport endpoint(EP_Transport)[1] and SFC on N6 interface(N6Protection)[2]. How 3GPP network slice trying to use the transport network is also described in their slice lifecycle management related documents, TS28.530 Clause 4.7 and, TS28.531 Clause 5.1 and 7.

As we received a liaison from GSMA NG, they have E2E Network Slicing Work Item(ENSWI) and I believe one of their objectives is to resolve the issue among multiple SDOs to realize E2E Network Slicing. Then, the response with the above Adrian's points may be useful.

https://mailarchive.ietf.org/arch/msg/teas/DZUhOW5m48tqj3CagfASM1BpDtg/

Also, not 3GPP, but ORAN alliance WG9 is actively working for xHaul solution standardization using other transport SDOs' specific solutions. I believe this also impacts mobile NEP's implementations and some TEASer are actively involved.

This may be beyond TEAS WG work, maybe related to DetNet, 3GPP SA2 started "Study on timing resiliency and TSC and URLLC enhancements" in Rel.18[3], which enhances URLLC slice with TSN requirement.

[1]https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2020-07-16-3gpp-tsg-sa-wg5-teas-ls-on-adding-transport-information-in-3gpp-nrm-to-facilitate-cross-domain-oam-coordination-attachment-2.doc
[2]https://www.3gpp.org/ftp/TSG_SA/WG5_TM/TSGS5_140e/Inbox/Drafts/S5-216247rev2%20Rel-17%20network%20slice%20protection%20on%20N6%20interface.docx
[3]https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3995

Cheers,
Adrian

Hi Kenichi / All

Kind Regards

Gyan

Interesting discussion.

All the best,
Kenichi

A

-----Original Message-----
From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 03 March 2022 08:23
To: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; Igor Bryskin <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

Hi all,

Agree with Joel.

Cheers,
Med

Gyan Mishra

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 6 Mar 2022 13:07:00 -0500

Hi Luis

Excellent!!

Gyan

On Sun, Mar 6, 2022 at 5:06 AM LUIS MIGUEL CONTRERAS MURILLO <
[email-masked]> wrote:

> Hi all,
>
>
>
> Just for you to know, I’m working on a draft on the mapping of 3GPP slices
> to IETF network slices, which I will upload before cutoff with the idea of
> being presented at IETF113. A complementary view, as well, on
> functionalities to be satisfied by IETF Network Slices to support different
> slice consumers can be found in draft-ietf-teas-ietf-network-slices, which
> is also in process to be updated for IETF113.
>
>
>
> Bets regards
>
>
>
> Luis
>
>
>
> *De:* Adrian Farrel <[email-masked]>
> *Enviado el:* sábado, 5 de marzo de 2022 10:42
> *Para:* 'Gyan Mishra' <[email-masked]>; 'Ogaki, Kenichi' <
> [email-masked]>
> *CC:* 'TEAS WG' <[email-masked]>; 'TEAS WG Chairs' <[email-masked]>;
> [email-masked]
> *Asunto:* RE: [Teas] Upcoming changes to
> I am not convinced that 5G will be **the** major consumer of IETF network
> slicing. But it is potentially **a** major consumer, so clearly our work
> must be good enough to support the 3GPP requirements.
>
>
>
> -          Other work is progressing at the working group (point at some
> drafts), and that input is always welcome
>
> -          The most effective way to contribute to and steer the work is
> by direct input from individuals via the mailing list
>
>
>
> Of course, those of you active in 3GPP or with friends who are, can make
> this go smoother by simply arranging for the reviews and input.
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* Gyan Mishra <[email-masked]>
> *Sent:* 04 March 2022 23:43
> *To:* Ogaki, Kenichi <[email-masked]>
> *Cc:* Igor Bryskin <[email-masked]>; Joel M. Halpern <
> [email-masked]>; TEAS WG <[email-masked]>; [email-masked];
> [email-masked]
> <https://www.gsma.com/newsroom/wp-content/uploads/NG.116-v5.0-7.pdf>
>
>
>
> All the best,
>
> Kenichi
>
>
>
> *Network Solutions Architect *
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is confidential and
> privileged information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 6 Mar 2022 13:27:42 -0500

Hi Kenichi / Adrian / Luis and all

Thank you Adrian for your comments and I agree with everything you have
stated.

I commented on a separate thread on your topic of 5G being the Major
consumer and agree to your POV that it is not the Major consumer, however
our work MUST be good enough to support 3GPP.

On Sun, Mar 6, 2022 at 6:06 AM Ogaki, Kenichi <[email-masked]> wrote:

> *From:* Adrian Farrel <[email-masked]>
> *Sent:* Saturday, March 5, 2022 6:42 PM
> *To:* 'Gyan Mishra'; 大垣 健一
> *Cc:* 'TEAS WG'; 'TEAS WG Chairs'; [email-masked]
> *Subject:* RE: [Teas] Upcoming changes to
> Gyan> Agree
>    - The most effective way to contribute to and steer the work is by
>    direct input from individuals via the mailing list
>
>
>
> [KO] From the above points, we can only provide the framework draft for
> now. A mapping draft, e.g. draft-geng-teas-network-slice-mapping or Luis’s,
> is individual and not matured. If you say
> draft-ietf-teas-ietf-network-slice-nbi-yang as the YANG model, it's also
> not matured.
>

    Gyan> Agreed

>
> In my understanding, the transport part of 3GPP network slice is not
> continuously discussed in 3GPP in terms of architecture, then they may not
> be able to be aware of what's the lack of IETF network slice if we only
> send the framework draft.

    Gyan> Agreed

>
> As for 3GPP network slice specification, I sometimes made comments to
> discussion threads about framework draft to avoid the inconsistency with
> other SDOs' work, especially 3GPP, as possible.
> I believe the current IETF network slice architecture is a superset of
> 3GPP network slice's one in terms of SLO, so not pessimistic.
>

    Gyan> Agreed.  Good point.  As far as Super set thinking in a
hierarchical terms or independent layering that have dependencies.  In
terms of hierarchy IETF sits at the top layer and underneath would sit the
individual Technologies such as 3GPP, Optical etc.  In my separate comment
I was alluding to hierarchical or a layering which IETF Network slice would
sit at the top of the hierarchy and being Technology agnostic and the
individual Technologies would sit at the bottom layer.  I wonder if a
comment on this layering topic should be in the framework draft?

>
> IMHO, a gap analysis is helpful, at first, based on their slice
> information model, TS28.541 Clause 6, which includes their slice related
> element relationship, SLO definition(ServiceProfile), transport
> endpoint(EP_Transport)[1] and SFC on N6 interface(N6Protection)[2]. How
> 3GPP network slice trying to use the transport network is also described in
> their slice lifecycle management related documents, TS28.530 Clause 4.7
> and, TS28.531 Clause 5.1 and 7.
>
> As we received a liaison from GSMA NG, they have E2E Network Slicing Work
> Item(ENSWI) and I believe one of their objectives is to resolve the issue
> among multiple SDOs to realize E2E Network Slicing. Then, the response with
> the above Adrian's points may be useful.
>
> Also, not 3GPP, but ORAN alliance WG9 is actively working for xHaul
> solution standardization using other transport SDOs' specific solutions. I
> believe this also impacts mobile NEP's implementations and some TEASer are
> actively involved.
>

    Gyan> Excellent

>
> This may be beyond TEAS WG work, maybe related to DetNet, 3GPP SA2 started
> "Study on timing resiliency and TSC and URLLC enhancements" in Rel.18[3],
> which enhances URLLC slice with TSN requirement.
>
> [1]
> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2020-07-16-3gpp-tsg-sa-wg5-teas-ls-on-adding-transport-information-in-3gpp-nrm-to-facilitate-cross-domain-oam-coordination-attachment-2.doc
> [2]
> https://www.3gpp.org/ftp/TSG_SA/WG5_TM/TSGS5_140e/Inbox/Drafts/S5-216247rev2%20Rel-17%20network%20slice%20protection%20on%20N6%20interface.docx
> [3]
> https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3995
>
>
>  Gyan> Agreed and great idea for sure
>
> Cheers,
>
> Adrian
>
>
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Igor Bryskin <[email-masked]>
Date: Sun, 6 Mar 2022 20:52:07 +0000 (UTC)

Hi Gyan,
You wrote that  the idea of network slicing existed long before 5G (which I totally agree), and that IETF network slicing is not limited to 5G (which  I am not sure). Two questions:1. Is there anything defined or needs to be defined in the NS framework  that is/will be not needed by 5G?
2. Is there anything defined or needs to be defined in the framework that has emerged  from clients not related to 5G?
If the answer for both questions is Nothing, how can we say that the framework is not limited to 5G?
Thanks,Igor

  On Sun, Mar 6, 2022 at 5:39 AM, Adrian Farrel<[email-masked]> wrote:   _______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 6 Mar 2022 19:02:41 -0500

Hi Igor

You bring up some really good questions of which I contemplated when
writing the email as well.

I think the tricky part that I believe we need WG consensus on is that as
“IETF Network slicing” has been solely driven the effort in its entirety by
5G, what is the harm with adding extensibility of this work beyond 5G.

The reason why this does come up as well as the extensibility beyond 5G is
that the basic mechanics exist which I called the lowest common denominator
which is the VPN overlay RFC 4364 which is integral and we IP VPN has
ubiquitous use cases that’s where the extensibility question comes up as to
why not.

As Adrian has stated in his response as well as the framework draft section
1 mentions use cases beyond 5G that could be possible.

Another point to note is we call it “IETF network slicing” not “5G Network
Slicing” and the term IETF opens the door to as well as restricts
applicability to IETF standards.  Of which 5G is not an IETF standard but
is a technology consumer of the “IETF network slice”

I think this discussion here is an important consideration when building
the framework draft as to the consumer of “IETF Network Slicing” .. is it
5G only or can it be open to other use cases ??

Answers in-line

Kind Regards

Gyan

On Sun, Mar 6, 2022 at 3:52 PM Igor Bryskin <[email-masked]> wrote:

> Hi Gyan,
>
> You wrote that
>  the idea of network slicing existed long before 5G (which I totally
> agree), and that IETF network slicing is not limited to 5G (which  I am not
> sure). Two questions:
> 1. Is there anything defined or needs to be defined in the NS framework
> that is/will be not needed by 5G?
>

   Gyan> I don’t think so in rev -8.  This is an authors question and maybe
more   a 3GPP expert question.

I believe the authors kept the open ended in mind the least common
denominator being VPN and now paradigm shift to Enhanced VPN that now the
door is open to other IETF standard technologies as consumers.  So I think
what we have in the framework draft can apply to 5G and beyond.

>
> 2. Is there anything defined or needs to be defined in the framework that
> has emerged  from clients not related to 5G?
>

   Gyan>  I would say the ideas of extensibility of the concept of an SLA
has always been a goal for operators but never formalized as we are doing
now with 5G requirements, however in cases as I mentioned with “network
slicing” the mechanisms have been there for a while with VPN traffic
steering and isolation so the ability o provide the concepts of isolation
has existed and as well now with SR has helped extend the mechanisms of
isolation with SR-TE micro and macro flow steering capabilities which would
answer your question as to what has emerged not related to 5G and solution
for operators.  However now I can see for sure with “IETF Network slicing”
fine SLA granularity can be extremely helpful to customers that require
more fine grain steering capabilities.  Definitely a value add for
customers provisioning Enhanced VPN with discrete NRP underlay resource
allocated for the E2E slice.

However, what  we have in rev 8 I believe accounts for all requirements
beyond 5G.  I believe the authors kept beyond 5G in the scoping all along.

> framework is not limited to 5G?

Gyan>So my  answers are nothing for both.

As I stated the least common denominator is IP VPN, so then all the 5G
requirements in rev 8 are all completely applicable to beyond 5G to any
customers wanting Enhanced VPN service wants a network slice provisioned
with some degree of isolation and are willing to pay for that top tier
service offering.

> On Sun, Mar 6, 2022 at 5:39 AM, Adrian Farrel
> <[email-masked]> wrote:

*Gyan Mishra*

*M 301 502-1347*

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 7 Mar 2022 01:22:22 +0000 (UTC)

Hi Gyan,
Thanks for the thoughtful and detailed response. Indeed, this is an important discussion.
1. IMHO IETF network slicing does not mean something wider than 5G network slicing. On the contrary, I'd argue it is narrower than 5G network slicing. It is  just a way to say that IETF cannot take care of 5G slicing end to end, rather, it can only focus on certain segments of 5G service (e.g. core network, back hawl, etc.), but not all (e.g. RAN).
2. The fact that things like VPN with SLOs existed as an idea for 20 years, but is taken  on realization  only now, after 5G came along (requiring the same SLOs) does not mean that we are defining something that is not limited to 5G - nothing prevents any client to take advantage of some/all  functions of 5G network slicing. This is just a lucky  byproduct.
3. The outcome of this discussion may have consequences that are not entirely harmless. For e ample, as we see in CCAMP,  because the framework stipulates  IETF network slicing to be not only about 5G, folks are already working on things like OTN slicing, and soon will be working on microwave and all other transport layer slicing. Do we really want to go there?
The bottom line: it would be helpful if the framework  indentified clearer/narrower its  focus. 
Cheers,Igor

  On Sun, Mar 6, 2022 at 7:07 PM, Gyan Mishra<[email-masked]> wrote:   _______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Tue, 8 Mar 2022 13:40:40 +0100

Hi,

Just wanted to add few words regarding 2nd bullet.

VPN with SLO is not only an idea, but has been implemented and in production at many operators since many years. Business Edge services (or Business VPN) type of offering is present at many service providers. It concluded isolated connectivity services between business sites, with some SLO. So, from that perspective, 5G doesn’t bring dramatic new requirements. Now, instead of business sites, we have mobile functions (RU, DU, CU, UPF, …) placed at different locations in the network, that require interconnection with some SLO.

Cheers,
Krzysztof

> On 2022 -Mar-07, at 02:22, Igor Bryskin <i_bryskin=[email-masked]> wrote:
> 
> Hi Gyan,
> 
> On Sun, Mar 6, 2022 at 7:07 PM, Gyan Mishra
> <[email-masked]> wrote:
> https://www.ietf.org/mailman/listinfo/teas <https://www.ietf.org/mailman/listinfo/teas>