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

[LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>]

Hi Reza,

Some doubts about your comments that come to my mind (not too much elaborated):

.- on SLO differentiation for TS members. Would not be more appropriate to consider different slices fitted to the specific SLOs for TS member? Otherwise, with the more stringent SLO you can ensure viability of the more relaxed ones, then why to differentiate? Because if we differentiate this basically means that we are solving the service in a different manner for the different members, thus going to the point of considering then different slices.

.- on adding attributes of the network slice to the transport slice. Here I think it is important to think which element should be aware of slicing association. As you mention a single transport slice can be used in context of multiple network slices (I think you made a typo there, correct me if I’m wrong). So, if that is the case, this implies that the transport slice should annotate multiple dependencies with different network slices. This can have some advantages, such as direct understanding on affected network slices in case a transport slice suffers problems. But maybe this can be also be obtained by looking the other way around, that is, being the network slice (through the upper system) the one registering the associated transport slice (or slices). Anyway, I need to think a bit more on this point, especially for the case when we could have different slice customers using different upper systems.

Best regards

Luis


De: Teas-ns-dt <[e-mail]> En nombre de Rokui, Reza (Nokia - CA/Ottawa)
Enviado el: viernes, 3 de abril de 2020 18:22
Para: Wubo (lana) <[e-mail]>om>; [e-mail]; [e-mail]; [e-mail]; Jari Arkko <[e-mail]>
CC: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>
Asunto: [Teas-ns-dt] Comments on draft-wd-teas-transport-slice-yang-00

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


________________________________

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 privileged and confidential 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