Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?

[Jeff Tantsura <[e-mail]>]

+1
Changes from QC(class)I to QF(flow)I decouple QoS settings from a bearer and are better expressed as multiple matrices per slice.

Cheers,
Jeff

> On Sep 28, 2021, at 11:53, Krzysztof Szarkowicz <[e-mail]> wrote:
> Igor,
> 
> Traffic type classification is required in any case. Assuming simple case, where traffic class is identified by DSCP, if case separate slice per class, the identification of NSE would be:
> 
> Currently defined NSE identification + DSCP
> 
> In case of multiple classes per slice, the identification of the NSE would stay the same, and then within the slice DCSP is used for class identification. Similar is already covered int L3SM/L2SM models. And, this is what John added recently as well top the slice draft, in fact.
> 
> Krzysztof
> 
>> On 2021 -Sep-28, at 20:33, Igor Bryskin <[e-mail]> wrote:
>> 
>> Krzysztof,
>> 
>> But in this case the slice NBI  would have to specify the traffic type classification rules, right?
>> Why is this better than to have the client to request separate slice per type?
>> 
>> Igor
>> 
>> Sent from Yahoo Mail on Android
>> 
>> On Tue, Sep 28, 2021 at 1:41 PM, Krzysztof Szarkowicz
>> <[e-mail]> wrote:
>> _______________________________________________
>> Teas mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/teas
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas