Re: [Teas] I-D Action: draft-wd-teas-ietf-network-slice-nbi-yang-05.txt

[Krzysztof Szarkowicz <[e-mail]>]

Hi Tarek,

Please see inline.

Thanks,
Krzysztof

> On 2021 -Sep-27, at 16:51, Tarek Saad <[e-mail] <mailto:[e-mail]>> wrote:
> 
> Hi Krzystof,
>  
> See inline.
>  
> From: Teas <[e-mail] <mailto:[e-mail]>> on behalf of Krzysztof Szarkowicz <[e-mail] <mailto:[e-mail]>>
> Date: Monday, September 27, 2021 at 3:44 AM
> To: Wubo (lana) <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>, [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [Teas] I-D Action: draft-wd-teas-ietf-network-slice-nbi-yang-05.txt
> 
> Hi,
> 
> Let me chime in to provide some feedback on the draft-wd-teas-ietf-network-slice-nbi-yang, from the 5G slicing perspective. There are couple of comments, I would like to provide.
> 
> 
> 1. Single 5G slice can incorporate multiple traffic classes, denoted by 3GPP as 5QI (5G QoS Identifier), and represented at the transport level with different DSCP values in GTP packets. Obviously, these different traffic classes within single slice have different SLO requirements, and I don't see in the proposed NBI any ways to specify SLO per traffic class (as for example available in L3SM or L2SM models)
> [TS]: fyi, the authors have started to discuss the possibility of extending SLOs to per traffic type (class) within the same slice the last time we have met. Currently, the model allows for specifying SLOs/SLEs on per connection(s) - which is aligned with I-D.draft-ietf-teas-ietf-network-slices. There is some discussion needed as to whether we would have a connectivity matrix per traffic type/class, or 1 connectivity matrix to carry multiple traffic types/classes. The modelling of SLO to connections for either case may vary depending on how it is realized.
> 
> 2. 5G slice might specify SLO requirements per connections, for example:
> 
>     UPF-1 ---> CU-1: guaranteed BW: 1G, maximum BW 2G
>     UPF-1 ---> CU-2: guaranteed BW: 1.5G, maximum BW 2G
>     UPF-1 ---> CU-3: guaranteed BW: 1.5G, maximum BW 3G
> 
> And additionally per groups of connections, i.e.:
> 
>    UPF-1 ---> <CU-1, CU-2, CU-3>: guaranteed BW: 4G, maximum BW 4G
> 
> I am not sure, how the above construct can be mapped to the proposed NBI (don’t even see the notation of both ‘guaranteed/max’, or CIR/PIR in MEF language, bandwidth).
> [TS]: we have a place-holder for ability to specify a shared SLO on to a connection group (set of connections) in the draft (it is incomplete in version -04). Once completed in next revision, it should address the above requirement .
> 
> 
> 3. Operators might have different strategies, how to implement traffic separation between the 5G slices at the transport level. As an example, operator A might decide to put N3 interfaces of one 5G slice in one L3VPN, while to put N6 interfaces on the same 5G slice in another L3VPN. On the other hand, operator B might decide to put both N3 and N6 interfaces of some 5G slice in common L3VPN. Each strategy has some disadvantage/advantage, but both strategies are valid. Similar, the control plane (i.e. A1, E2, O1 interfaces ), operators might decide that some 5G slices shares L3VPN for control plane, while some other 5G slices use separate L3VPN for control plane. I don’t see anything in the NBI to address this.
> 
> 4. NBI attempts to be ‘abstract and technology-agnostic’, while when talking about mapping 5G slices to transport, folks are talking about L3VPNs, DCSP/Exp values, etc., which will require porting of significant part of current L3SM/L2SM models into proposed NBI model in order to make it applicable for 5G slicing.
> 
> 
> All if this makes me believe, that augmenting of existing L3SM/L2SM models is better strategy for NBI for 5G slicing.
> [TS]: One of the design objective is to keep the network slice service technology independent – i.e. the network slice may well be realized over L2/L3 or even L1 networks, and the choice to pick what technology to support a network slice service would be solution/operator dependent and may also depend on where (access/agg/core) the network slice service is being realized.
> From modelling perspective, I think it is less favorable (and more tedious) to augment multiple service models (and to keep augmentations in sync when additions are made). That said, IMO some groupings (or data that is already defined in LxSM) may be imported and reused in the network slice service model if that makes sense.

[Krzysztof] Again, 5G slicing intend, at the transport layer, in midhaul and backhaul segments of the network, is about L3VPNs (for traffic separation between different slices), and about specifying SLOs for the point-to-point transport demands interconnecting different 5G components (e.g. interconnecting UPF-X with CU-Y, or CU-Y with DU-Z). As mentioned earlier, different operators might have different strategy, how to do separation (how many L3VPNs), but I don’t see anything about that in draft-wd-teas-ietf-network-slice-nbi-yang. So, my understanding is, the higher level 5G orchestrator (SMO) would be required to use both draft-wd-teas-ietf-network-slice-nbi-yang and e.g. LxSM to specify the full intend (unless significant part of LxSM is ported to draft-wd-teas-ietf-network-slice-nbi-yang). This is not very efficient.



>  
> Regards,
> Tarek
> 
> Best regards,
> Krzysztof Szarkowicz
> 
> > On 2021 -Sep-26, at 11:13, Wubo (lana) <[e-mail] <mailto:[e-mail]>> wrote:
> > 
> > Hi all,
> > 
> > Revision-05 adds a new section, sec 4. Background on IETF Network Slice Service Modeling. We give an analysis on why a new network slice YANG model is needed instead of reusing LxSM or augmenting ACTN VN.
> > 
> > Thanks,
> > Bo
> > 
> > -----邮件原件-----
> > 发件人: Teas [mailto:[e-mail] <mailto:[e-mail]>] 代表 [e-mail] <mailto:[e-mail]>
> > 发送时间: 2021年9月26日 16:42
> > 收件人: [e-mail] <mailto:[e-mail]>
> > 抄送: [e-mail] <mailto:[e-mail]>
> > 主题: [Teas] I-D Action: draft-wd-teas-ietf-network-slice-nbi-yang-05.txt
> > 
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF.
> > 
> >        Title           : IETF Network Slice Service YANG Model
> >        Authors         : Bo Wu
> >                          Dhruv Dhody
> >                          Reza Rokui
> >                          Tarek Saad
> >                          Liuyan Han
> >                          Luis Miguel Contreras
> >        Filename        : draft-wd-teas-ietf-network-slice-nbi-yang-05.txt
> >        Pages           : 49
> >        Date            : 2021-09-26
> > 
> > Abstract:
> >   This document provides a YANG data model for the IETF Network Slice
> >   service.  The model can be used by a IETF Network Slice Customer to
> >   manage IETF Network Slice from an IETF Network Slice Controller
> >   (NSC).
> > 
> > 
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-wd-teas-ietf-network-slice-nbi-yang/ <https://datatracker.ietf.org/doc/draft-wd-teas-ietf-network-slice-nbi-yang/>
> > 
> > There is also an htmlized version available at:
> > https://datatracker.ietf.org/doc/html/draft-wd-teas-ietf-network-slice-nbi-yang-05 <https://datatracker.ietf.org/doc/html/draft-wd-teas-ietf-network-slice-nbi-yang-05>
> > 
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-wd-teas-ietf-network-slice-nbi-yang-05 <https://www.ietf.org/rfcdiff?url2=draft-wd-teas-ietf-network-slice-nbi-yang-05>
> > 
> > 
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> > 
> > 
> > _______________________________________________
> > Teas mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/teas <https://www.ietf.org/mailman/listinfo/teas>
> > _______________________________________________
> > Teas mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/teas <https://www.ietf.org/mailman/listinfo/teas>
> 
> _______________________________________________
> Teas mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/teas <https://www.ietf.org/mailman/listinfo/teas>