[Teas-ns-dt] Comments on draft-wd-teas-transport-slice-yang-00

["Rokui, Reza (Nokia - CA/Ottawa)" <[e-mail]>]

Hi Bo et al.,

As per our discussion during the NSDT call, I have reviewed the NBI modeling draft draft-wd-teas-transport-slice-yang-00.
It is a good draft and is aligned with my thought as well.

These are my few comments:


  1.  Referring to the picture below (Figure-1 in draft), in some cases it is desired to have different SLOs for a sub-group of TS-Members. For example the TS-member 1 and 2 can have SLO_Red whereas TS-member 3 and 4 can have SLO_Green. If we consider this concept as part of our NBI modeling, it creates lots of flexibility for any use-case which wants to use our NBI model.

As a  result, I am suggesting to introduce the concept of Connection Group shown below.

Note that since the concept of network slicing is new, we need to be flexible in our modeling and as a result the concept of Connection Group creates a tremendous flexibility for any future use-cases which want to use our transport slice model.

A typical example in case of 5G network slicing. It is potentially possible (and it depends on the MNO operator) to have a transport slice which contains both control plane and data plane. In this case the SLO for control and data planes are different.



For example for the example shown in Figure 1, we will have the following structure for a single transport slice


      Transport slice #1 {
           Connection group Red:{
               TS-Member 1      EP1-EP2 --> with SLO_Red
               TS-Member 2      EP1-EP3 --> with SLO_Red
           }
           Connection group Green:{
               TS-Member 3      EP2-EP3 --> with SLO_Green
               TS-Member 4      EP2-EP4 --> with SLO_Green
           }


                 +--------------------------+
                 |                          |
  +-----+  /--\  |                          |  /--\   +-------+
  |     +-+ EP1+-+                          +-+ EP3+--+ Site2 |
  |Site1|  \--/  |                          |  \--/   +-------+
  |     |        |                          |
  |     |  /--\  |                          |  /--\   +-------+
  |     +-+ EP2|-+                          +-+ EP4+--+ Site3 |
  +-----+  \--/  |                          |  \--/   +-------+
                 |        Transport         |
                 |        Network           |
                 +--------------------------+
            |                                    |
            |<-----Transport Slice n------------>|
            |                                    |


  1.  It will be beneficial to further assurance on transport slice to have some attributes of the network slice to be included in transpot slice model. Note that, these attributes are not needed for realization of the transport slice but will be beneficial for further assurance which maps the transport slice to network slice. In particular, transport slice to network slice is one to many mapping which means that a single transport slice can be used in context of multiple transport slices.

As a result, I am suggesting to add the following building block to the definition of a single transport slice:


      Transport slice #1

        +--rw network-slice* [ns-id]
           +--rw ns-id          uint32
           +--rw ns-name?       string
           +--rw ns-other-info  identityref
           +--rw ns-other-info  identityref
           +--...
           +--...


  1.  To make the transport slice data model more generic, I am suggestion to introduce three policies
     *   transport-slice-slo-policy
                              This is a mandatory policy.  This policy represents in a generic and technology-agnostics way the SLO requirement needed to realize a group of connections which are part of a transport slice.


     *   transport-slice-selection-policy

               This is an optional policy.  In some deployment, the E2E high level system (as defined in definition draft) might want to assist the transport slice controller on how to realize a transport slice by providing some information regarding the type of technologies and tunnels.  This information will be provided in this policy.



     *   transport-slice-assurance-policy

               This is an optional policy.  The E2E high level system (as defined in definition draft) shall influence the transport slice controller for transport slice assurance on how to perform transport slice assurance. To this end, the transport-slice-assurance-policy will be used.  It contains, the type of assurance needed, time interval, how often inform the E2E network slice controller etc.



  1.  As per my comment 3 above, some of the following attributes can be represented by transport slice policies. We need to talk about the other attributes during the call.



           |  +--rw bandwidth-slo

           |  |  +--rw incoming-bandwidth

           |  |  |  +--rw guaranteed-bandwidth?   te-types:te-bandwidth

           |  |  |  +--rw max-bandwidth?          te-types:te-bandwidth

           |  |  +--rw outgoing-bandwidth

           |  |     +--rw guaranteed-bandwidth?   te-types:te-bandwidth

           |  |     +--rw max-bandwidth?          te-types:te-bandwidth

           |  +--rw mtu                       uint16

           |  +--rw ts-traffic-criteria

           |  |  +--rw vlan?            uint8

           |  |  +--rw dscp?            inet:dscp

           |  |  +--rw src-ip-prefix?   inet:ip-prefix

           |  +--rw status

           |  |  +--rw admin-enabled?   boolean

           |  |  +--ro oper-status?     operational-type

           |  +--ro ep-monitoring

           |     +--ro incoming-utilized-bandwidth?

           |     |       te-types:te-bandwidth

           |     +--ro incoming-bw-utilization        decimal64

           |     +--ro outgoing-utilized-bandwidth?

           |     |       te-types:te-bandwidth

           |     +--ro outgoing-bw-utilization        decimal64


That’s it for now.

Cheers,
Reza