Re: [Teas] ***フリーメール*** Re: ***フリーメール*** Re: Network slicing framework : Issue #2 : How many connectivity matrices in a slice?

[Krzysztof Szarkowicz <[e-mail]>]

Kenichi,

What me (and others) are saying is, that the architecture should be flexible enough to support uses cases with:

1) no class differentiation within the slice (this is the use case you are looking for)
2) as well as use cases with class differentiation within the slice.

Both use cases can coexist, so no one is hurt :-). For use case (1), SLO/SLE is per slice. For use case (2), SLO/SLE is per traffic class (group of flows).

Thanks,
Krzysztof


> On 2021 -Sep-29, at 03:18, Ogaki, Kenichi <[e-mail] <mailto:[e-mail]>> wrote:
> 
> Hi Krzysztof and All,
>  
> Let me explain what makes us feel strangeness, please.
>  
> I believe all your technology and solution related comments are correct.
> This is just a terminology concern.
>  
> From an operator's service perspective, we have to charge to a customer for how much resource is assigned/used fundamentally.
>  
> How to assign the resources is a little bit different from IETF's basic existing solutions from the other SDO's slice solution.
> When we assume a router network, IETF slice may be realized by Adrian's filtered topology that basically assigns bandwidth on top of an existing physical router network. Providing multiple QoS classification inside the bandwidth doesn't affect the assigned resource although the router processing resource is consumed, but this can be incorporated as an assigned resource.
> The other SDO's slice solution, especially 3GPP, is a kind of SFC, but the node providing an SF may be newly created per slice, e.g. UPF for URLLC slice service. So, 3GPP defines an SFC-like instance as their Network Slice Instance in my understanding. In other words, they have a Network Slice Instance per a set of SLOs/SLEs, i.e. "ServiceProfile" which I wrote.
>  
> Again, from a service perspective, it's simple for providers that a service has 1:1 relationship with a set of SLOs/SLEs.
> I agree it's possible to have multiple mappings of a connectivity matrix to a set of SLOs/SLEs under a slice (service).
> We are concerned about the inconsistency of the hierarchical concept with the other SDOs and bringing a confusion to use ietf network slice as their transport network.
> So, our main point is if a slice service should have multiple sets of SLOs/SLEs. Is that *a* service?
>  
> Here is IETF, then IETF network slice should be defined regardless of the other SDOs’ definition. I understand.
>  
> See reply inline[KO], please.
>  
> Thanks,
> Kenichi
>  
> From: Krzysztof Szarkowicz <[e-mail] <mailto:[e-mail]>> 
> Sent: Wednesday, September 29, 2021 2:38 AM
> To: 大垣 健一 <[e-mail] <mailto:[e-mail]>>
> Cc: John E Drake <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; TEAS WG <[e-mail] <mailto:[e-mail]>>
> Subject: ***フリーメール*** Re: [Teas] ***フリーメール*** Re: Network slicing framework : Issue #2 : How many connectivity matrices in a slice?
>  
> Hi Kenichi,
>  
> Please see inline,
>  
> Thanks,
> Krzysztof
> 
> 
> On 2021 -Sep-28, at 16:52, Ogaki, Kenichi <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Hi Krzysztof,
>  
> It depends on what's class?
> If the class is that of DSCP, and a single slice just prioritizes the traffic on the same topology, we don't mind.
> 
> [Krzysztof] Yes. But even if they are they are forwarded across the same path, they could have different capacity requirements -> how this capacity is requested via NBI? I.e. 1G for QCI ‘X’ + 1G for QCI ‘Y’, is not the same as 2G for aggregate of QCI ‘X’+’Y’.
>  
> [KO] Again in 3GPP semantics, there is two options where the underlying topology is same.
> Option 1:
> Creating two slices per capacity requirement.
> Slice 1 with ServiceProfile X:
> dlThptPerUE 1Gbps
> ulThptPerUE 1Gbps
> 
> Slice 1 with ServiceProfile Y:
> dlThptPerUE 1Gbps
> ulThptPerUE 1Gbps
>  
> Option 2:
> Creating a slice with the QoS profile
> Slice 3 with ServiceProfile “X+Y” and EP Transport/qosProfile* “X+Y”
> ServiceProfile “X+Y”
> dlThptPerUE 2Gbps
> ulThptPerUE 2Gbps
> EP_Transport/qosProfile “X+Y”
> QCI X 1Gbps
> QCI Y 1Gbps
>  
> *See TS28.541 Rel.17 Clause 6.3.2.2 and 6.3.1.17, and “S5-203253 TD proposal to add transport endpoint in NRM.doc”
> 3GPP slice NRM, like an information model for the NBI, can have a QoS profile as an SLO. It depends on the implementation, but we can profile H-QoS? inside an assigned resource.
>  
> In this case, almost of all customers and providers does Option 2.
>  
>  
> But, the class includes the latency like your QCI examples. We have to create different underlying topology per class. It's complicated to manage the relationship of n topologies to 1 slice.
> Again in 3GPP semantics, we have to definitely create a different Network Slice Instance for your 3rd QCI. The UPF must be placed near the UE location and its deployment costs more.
> For providers like us, we have to charge for a slice service. It's simple that URLLC slice service charges xxx JPY per month, BE slice service charges yyy JPY per month. But, this is just terminology mapping issue.
>  
> [Krzysztof] Agreed.
> 
> 
> So, what term should we use against an *Service* Level Objective? connectivity matrix or slice (service)?
> 
> Thanks,
> Kenichi
>  
> Get Outlook for iOS <https://aka.ms/o0ukef>
> From: John E Drake <[e-mail] <mailto:[e-mail]>>
> Sent: Tuesday, September 28, 2021 11:20 PM
> To: Krzysztof Szarkowicz; 大垣 健一
> Cc: [e-mail] <mailto:[e-mail]>; TEAS WG
> Subject: RE: [Teas] ***フリーメール*** Re: Network slicing framework : Issue #2 : How many connectivity matrices in a slice?
>  
> Hi,
>  
> Comment inline below.
>  
> Yours Irrespectively,
>  
> John
>  
>  
> Juniper Business Use Only
> From: Krzysztof Szarkowicz <[e-mail] <mailto:[e-mail]>> 
> Sent: Tuesday, September 28, 2021 9:58 AM
> To: Ogaki, Kenichi <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>; John E Drake <[e-mail] <mailto:[e-mail]>>; TEAS WG <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [Teas] ***フリーメール*** Re: Network slicing framework : Issue #2 : How many connectivity matrices in a slice?
>  
> [External Email. Be cautious of content]
>  
> Hi Kenichi, 
>  
> We might ask to create different 3GGP slices. At the same point, having multiple classes within single 3GPP slice is completely valid approach, too.
>  
> Further, slice (with multiple classes) might be requested by other consumers (not only 3GPP SMO), not related to mobile.
>  
> My main point is, IETF network slicing architecture must be prepared to handle slice requests with multiple traffic classes within the slice, and should not be restricted to support only slicing request with single traffic class per slice, as with this restriction many use cases will be limited.
>  
> [JD]  I completely agree with this.  Further, as I noted yesterday:
>    
> Attachment Circuit (AC):  A channel connecting a CE and a PE over which packets are exchanged.  The customer and provider agree on which values in which combination of L2 and L3 fields within a packet identify a given connectivity matrix within a given IETF Network Slice Service.
>  
> Thanks,
> Krzysztof
>  
>  
> On 2021 -Sep-28, at 15:07, Ogaki, Kenichi <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Hi Krzysztof,
>  
> >If the slice have flows from following three QCIs:
> 
> >1: Conversational Voice, latency 100 ms, 10 Mbps
> >76: Live Uplink Streaming, latency 500 ms, 100 Mbps
> >80: Low latency eMBB applications (TCP/UDP-based); Augmented Reality, Latency 10 ms, 1 Gbps
> 
> >What SLO would you request for this slice?
> 
> In the 3GPP semantics, we ask NSMF, 3GPP Mgmt system, to create three slices with each "ServiceProfile".
> 
> Slice 1 with ServiceProfile 1:
> latency 100ms
> dlThptPerUE 10Mbps
> ulThptPerUE 10Mbps
> 
> Slice 2 with ServiceProfile 76:
> latency 500ms
> ulThptPerUE 100Mbps
> 
> Slice 3 with ServiceProfile 80:
> latency 10ms
> dlThptPerUE 1Gbps
> dlThptPerUE 1Gbps
> 
> Slice 1 and 2 may be merged into a Slice 4, but Slice 3 is definitely different characteristics. Then, we have to create different slices. 
> 
> Thanks,
> Kenichi
>  
> Get Outlook for iOS <https://urldefense.com/v3/__https:/aka.ms/o0ukef__;!!NEt6yMaO-gk!VsbJbYkwr6R-YeGQzaqizMbCI51rrxrfAluYOGtf09gsMEGYbjltuaQIhHesicc$>
> From: Adrian Farrel <[e-mail] <mailto:[e-mail]>>
> Sent: Tuesday, September 28, 2021 9:58 PM
> To: 'Krzysztof Szarkowicz'
> Cc: 大垣 健一; 'John E Drake'; 'TEAS WG'
> Subject: RE: [Teas] ***フリーメール*** Re: Network slicing framework : Issue #2 : How many connectivity matrices in a slice? 
>  
> Just asking.
>  
> If your answer is “because the 3GPP slice has all these different SLOs and we want to maintain a strict n:1 mapping of e2e slice to transport slice” then that is a great answer.
>  
> A
>  
> From: Krzysztof Szarkowicz <[e-mail] <mailto:[e-mail]>> 
> Sent: 28 September 2021 13:49
> To: [e-mail] <mailto:[e-mail]>
> Cc: Ogaki, Kenichi <[e-mail] <mailto:[e-mail]>>; John E Drake <jdrake=[e-mail] <mailto:jdrake=[e-mail]>>; TEAS WG <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [Teas] ***フリーメール*** Re: Network slicing framework : Issue #2 : How many connectivity matrices in a slice?
>  
> Hi Adrian,
>  
> You mean, you recommend to map single 3GPP slice, to multiple IETF slices, based on traffic class?
>  
> Thanks,
> Krzysztof
>  
> On 2021 -Sep-28, at 14:46, Adrian Farrel <[e-mail] <mailto:[e-mail]>> wrote:
>  
> It’s a good question, but in this case, why do you not have three slices?
>  
> A
>  
> From: Krzysztof Szarkowicz <[e-mail] <mailto:[e-mail]>> 
> Sent: 28 September 2021 13:45
> To: Ogaki, Kenichi <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>; John E Drake <jdrake=[e-mail] <mailto:jdrake=[e-mail]>>; TEAS WG <[e-mail] <mailto:[e-mail]>>
> Subject: Re: ***フリーメール*** Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?
>  
> Hi Kenichi,
>  
> If the slice have flows from following three QCIs:
>  
> 1: Conversational Voice, latency 100 ms, 10 Mbps
> 76: Live Uplink Streaming, latency 500 ms, 100 Mbps
> 80: Low latency eMBB applications (TCP/UDP-based); Augmented Reality, Latency 10 ms, 1 Gbps
>  
> What SLO would you request for this slice?
>  
> Thanks,
> Krzysztof
>  
>  
>  
> On 2021 -Sep-28, at 14:03, Ogaki, Kenichi <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Hi Krzysztof,
>  
> Yes. A 3GPP slice supports multiple QoS, but this doesn't mean each QoS is necessarily associated with an SLO in my understanding.
> A 3GPP slice is characterized with a slice NRM defined in TS28.541 Clause 6. Especially 6.3.3, "ServiceProfile" is corresponded to a set of SLOs/SLEs in ietf network slice.
> We can map each QoS flow to a "SeriviceProfile", but this is not necessary.
>  
> Thanks,
> Kenichi
>  
> Get Outlook for iOS <https://urldefense.com/v3/__https:/aka.ms/o0ukef__;!!NEt6yMaO-gk!VsbJbYkwr6R-YeGQzaqizMbCI51rrxrfAluYOGtf09gsMEGYbjltuaQIhHesicc$>
> From: Krzysztof Szarkowicz <[e-mail] <mailto:[e-mail]>>
> Sent: Tuesday, September 28, 2021 8:39 PM
> To: [e-mail] <mailto:[e-mail]>
> Cc: John E Drake; TEAS WG; 大垣 健一
> Subject: ***フリーメール*** Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?
>  
> My 2 cents:
> 
> Slice might have multiple QoS flows (i.e 3GPP TS 38.300, Section 16.3.1), and obviously these different QoS flows will have different SLO characteristics (even, if the set of end-points is the same for all QoS flows).
> 
> So, if the support for mapping 3GPP slices to IETF slices is desired, certainly allowing multiple connectivity matrixes per slice would be welcomed.
> 
> Best regards,
> Krzysztof
> 
> 
> > On 2021 -Sep-28, at 10:47, Ogaki, Kenichi <[e-mail] <mailto:[e-mail]>> wrote:
> > 
> > Hi Adrian,
> > 
> > This is just how we define a slice. We are concerned that we should allow multiple SLO/SLEs inside a slice?
> > We prefer not doing so since other SDOs define that their slice is determined with a SLO/SLE in my understanding.
> > Inside a slice with a common SLO/SLE, we don't mind multiple connectivity matrices, but we're not sure the necessity.
> > 
> > Thanks,
> > Kenichi
> > 
> > -----Original Message-----
> > From: Teas <[e-mail] <mailto:[e-mail]>> On Behalf Of John E Drake
> > Sent: Tuesday, September 28, 2021 3:17 AM
> > To: [e-mail] <mailto:[e-mail]>; 'TEAS WG' <[e-mail] <mailto:[e-mail]>>
> > Subject: Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?
> > 
> > Adrian,
> > 
> > In the latest version of the to-be-published Framework draft, we have the following definition:
> > 
> > Attachment Circuit (AC):  A channel connecting a CE and a PE over which packets are exchanged.  The customer and provider agree on which values in which combination of L2 and L3 fields within a packet identify a given connectivity matrix within a given IETF Network Slice Service.
> > 
> > Yours Irrespectively,
> > 
> > John
> > 
> > 
> > Juniper Business Use Only
> > 
> >> -----Original Message-----
> >> From: Teas <[e-mail] <mailto:[e-mail]>> On Behalf Of Adrian Farrel
> >> Sent: Monday, September 27, 2021 12:29 PM
> >> To: 'TEAS WG' <[e-mail] <mailto:[e-mail]>>
> >> Subject: [Teas] Network slicing framework : Issue #2 : How many 
> >> connectivity matrices in a slice?
> >> 
> >> [External Email. Be cautious of content]
> >> 
> >> 
> >> Hi,
> >> 
> >> Igor raised this especially in the context of how traffic is 
> >> identified for association with a connectivity matrix that belongs to a slice.
> >> 
> >> Consider the definition of connectivity matrix in the current draft 
> >> and as discussed in issue #1.
> >> 
> >> A consumer may want multiple connectivity matrices in their "contract" 
> >> with the provider. In the example with four edge nodes (A, B, C, D), 
> >> their may be traffic that flows between some edges, but not between others.
> >> 
> >> For example, a consumer may want a slice that is ultra-low latency, 
> >> and they may know that they want to send traffic from A to B, from A 
> >> to C and multicast from D to A, B, and C.
> >> 
> >> It is, of course, possible to express this as three separate slices. 
> >> And this is perfectly acceptable. We must not make any definitions 
> >> that prevent this from being the case.
> >> 
> >> However, it seems likely that the consumer (and the operator) would 
> >> prefer to talk about "the consumer's low latency slice". That is, to 
> >> bundle these three connections into one construct. However, they are 
> >> distinctly different connections and must be understood as such. 
> >> Indeed, they may have some different SLOs associated (for example, A-B 
> >> may require more bandwidth than A-C).
> >> 
> >> By allowing (but not mandating) multiple connectivity matrices in a 
> >> single slice service, we facilitate this administrative group.
> >> 
> >> One could also imagine (but I do not pre-judge the network slice 
> >> service YANG model definition) a default set of SLOs that apply to all 
> >> connectivity matrices in a slice, and specific modified SLOs per connectivity matrix.
> >> 
> >> Now, to Igor's point. This is about how traffic arriving at an edge 
> >> (say a PE) is mapped to the correct connection. I promised a Venn 
> >> diagram, but words are easier 😊
> >> 
> >> If we take the model of a port-based VPN, then one approach might be 
> >> to map the (virtual or physical) port number or VLAN ID to the network 
> >> slice. But clearly (and this was Igor's point) this doesn't identify 
> >> the connectivity matrix if there is more than one matric per slice.
> >> 
> >> A solution I offered is that the VLAN ID could identify {slice, connectivity matrix}.
> >> At that PE, for a given AC to a CE, it is necessary to expose with a 
> >> separate VLAN ID for each {slice, connectivity matrix}. That does not mean:
> >> - we need a global unique identifier for each connectivity matrix
> >> - we need a per-PE unique identifier for each connectivity matrix
> >> 
> >> I am *very* cautious about discussing potential technology solutions 
> >> because they are just that. It is not the business of a framework to direct solutions work.
> >> But I provide this example solution just to show that it is possible.
> >> 
> >> Consider also, how traffic is placed on LSPs or on SFCs. The answer is 
> >> that there is some form of classification performed at the head end. 
> >> In many cases, this is as simple as examination of the destination 
> >> address (traffic is "routed" onto the LSP). In other cases there is 
> >> deeper analysis of the 5-tuple and even other packet parameters. Often this will be enough, but when there are multiple "parallel"
> >> connections to the same destination, some form of choice must be made: 
> >> how that choice is made can be configured in an implementation, and 
> >> may include looking at additional information (such as a VLAN ID) passed from the consumer.
> >> 
> >> Note that the identity of the connectivity matrix is not needed 
> >> anywhere except at the ingress edge node. It may be that the 
> >> connectivity matrix is mapped to some internal network structure (such 
> >> as an LSP) and that that provides an implicit identification of the 
> >> connectivity matrix, and it may be that a solution technology chooses 
> >> to keep an identifier of the connectivity matrix with each packet, but that is not a requirement of the architecture.
> >> 
> >> I think what I have said is:
> >> - Support of one connectivity matrix per slice is mandatory
> >> - Support of more than one connectivity matrix per slice is in the architecture
> >>  but is optional to implement
> >> - There are ways that a protocol solution could achieve this function
> >> - I have heard some voices asking for the association of multiple connectivity
> >>  matrices with a single slice
> >> - I have not heard anyone providing examples of harm this would cause
> >> 
> >> Please discuss.
> >> 
> >> Adrian
> >> 
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> Teas mailing list
> >> [e-mail] <mailto:[e-mail]>
> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas>
> >> __;!!N
> >> Et6yMaO-
> >> gk!WDr1qyYuWTVcNfdWACFDBhpuWB09hOnRKbD4lEp5p3xxVzN2mQcQ2Ioh45
> >> z7At0$
> > _______________________________________________
> > Teas mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/teas <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!VsbJbYkwr6R-YeGQzaqizMbCI51rrxrfAluYOGtf09gsMEGYbjltuaQIWH5hXmA$>
> > _______________________________________________
> > Teas mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/teas <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!VsbJbYkwr6R-YeGQzaqizMbCI51rrxrfAluYOGtf09gsMEGYbjltuaQIWH5hXmA$>
>  
> _______________________________________________
> Teas mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/teas <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!VsbJbYkwr6R-YeGQzaqizMbCI51rrxrfAluYOGtf09gsMEGYbjltuaQIWH5hXmA$>
>  
> _______________________________________________
> Teas mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/teas <https://www.ietf.org/mailman/listinfo/teas>