Updating slicing section of 05-osm-usage

### Resources

For the session, we need a set of resources (VNFs, NSs, NSTs) that are available in the following [link](https://osm-download.etsi.org/ftp/osm-6.0-six/8th-hackfest/packages/)

This network slicing example of usage requires a set of resources (VNFs, NSs, NSTs) that are available in the following [link](https://osm-download.etsi.org/ftp/osm-6.0-six/8th-hackfest/packages/)

- [slice_hackfest_vnfd.tar.gz](https://osm-download.etsi.org/ftp/osm-6.0-six/8th-hackfest/packages/slice_hackfest_vnfd.tar.gz)

- [slice_hackfest_middle_vnfd.tar.gz](https://osm-download.etsi.org/ftp/osm-6.0-six/8th-hackfest/packages/slice_hackfest_middle_vnfd.tar.gz)

### Network Slice Template Diagram

The diagram below shows the Network Slice Template we are going to develop in this session. As you can see, we have three network slice subnets, connected by Virtual Links Descriptors (VLDs) through the connection points of the network services. We have a Virtual Link for management slice_vld_mgmt and two Virtual links for data, slice_vld_data1 and slice_vld_data2. In the middle, we have a network-slice-subnet that interconnects the Netslice subnet we have on the left side to the Netslice subnet in have on the right side.

The diagram below shows the Network Slice Template created for the example. As is shown in the picture, three network slice subnets are connected by Virtual Links Descriptors (VLDs) through the connection points of the network services. We have a Virtual Link for management slice_vld_mgmt and two Virtual links for data, slice_vld_data1 and slice_vld_data2. In the middle, we have a network-slice-subnet that interconnects the Netslice subnets we have on both sides.

![nst diagram](assets/800px-nst.png)

#### Virtual Network Functions

The VNFs used for this session are two. The difference between them is the number of interfaces that have to create the connections. While the *slice_hackfest_middle_vnfd* VNF have three interfaces (mgmt, data1, data2), the *slice_hackfest_vnfd* have only two (mgmt, data). The rest of the specifications are the same as 1vCPU, 1GB of RAM, 10GB of disk, and image-name 'US1604' that is the ubuntu 16.04 image.

We use two VNFs for this example. The difference between them is the number of network interfaces to create connections. While the *slice_hackfest_middle_vnfd* VNF have three interfaces (mgmt, data1, data2), the *slice_hackfest_vnfd* have only two (mgmt, data). The specifications vCPU (1), RAM (1GB), disk (10GB), and image-name ('US1604') are the same in both VNFs.

![vnfd](assets/800px-vnfd.png)

#### Network Services

Two network services are needed for this session. The network services differ in the number of interfaces that posses and the VNF that is contained inside the Network service. The NS *slice_hackfest_nsd* has two VLDs, one for data and other for management while the *slice_hackfest_middle_nsd* has three VLDs, one for management and the other two for data1 and data2.

We use two network services in this example. They are differentiated by 1) the number of interfaces that posses, 2) the VNF contained inside the Network service, 3) the NS *slice_hackfest_nsd* have two VLDs, one for data and other for management 4) the *slice_hackfest_middle_nsd* has three VLDs, one for management and the other two for data1 and data2.

Inside *slice_hackfest_middle_nsd* we have the *slice_hackfest_middle_vnfd* and *slice_hackfest_nsd* posses the vnf *slice_hackfest_vnfd*.

The *slice_hackfest_middle_nsd* have inside the *slice_hackfest_middle_vnfd* and the *slice_hackfest_nsd* has the vnf *slice_hackfest_vnfd*.

The diagram below shows the *slice_hackfest_nsd* and *slice_hackfest_middle_nsd*, its connection points, vlds and vnfs.

The diagram below shows the *slice_hackfest_nsd* and *slice_hackfest_middle_nsd*, its connection points, VLDs and VNFs.

![nsd](assets/800px-nsd.png)

### Creating a Network Slice Template (NST)

Based on the OSM information model for Network slice templates [here](http://osm-download.etsi.org/repository/osm/debian/ReleaseSIX/docs/osm-im/osm_im_trees/nst.html) we can write the YAML descriptor for the NST. Let's dissect part by part the NST:

Based on the OSM information model for Network slice templates [here](http://osm-download.etsi.org/repository/osm/debian/ReleaseSIX/docs/osm-im/osm_im_trees/nst.html) it is possible to start writing the YAML descriptor for the NST.

```yaml

nst:

        slice-service-type: eMBB

    quality-of-service:

        id: 1

```

The snippet above, we set an id and name for the network slice template, and we specify the required parameter *SNSSAI-identifier* to have a reference which kind of service will be deployed inside this slice. Additionally, we add a *quality-of-service* parameter that will be used in future releases of OSM.

The snippet above contains the mandatory fields for the NST. Additionally, we can find the description below of the 'netslice-subnet' and 'netslice-vld' sections. When we create an NST, the 'id' references the Network Slice Template, and the 'name' is the name set to the NST. Additionally, the required parameter *SNSSAI-identifier* is a reference to which kind of service is inside this slice. In OSM we have three types of slice-service-type. Enhanced mobile broadband (eMBB), Ultra-reliable low-latency communications (URLLC) or massive machine type communications (mMTC). Moreover, we add a *quality-of-service* parameter that is related to the 5G QoS Indicator (5QI).

The section *netslice-subnet* shown below is the place to allocate the network services that compose the slice. Each item of the *netslice-subnet* list has:

After setting the id, name and some required parameters, we need to define which network services will compose our network slice template. The section *netslice-subnet* looks like:

1) An `id` to identify the netslice-subnet.

2) The option `is-shared-nss` is a boolean flag to determine if the NSS is shared among Network Slice Instances that use this Netslice Subnet.

3) An optional `description`.

4) The `nsd-ref`  is the reference to the Network Service descriptor that forms the netslice subnet.

```yaml

 netslice-subnet:

        nsd-ref: slice_hackfest_nsd

```

Each item of the *netslice-subnet* list requires an id to identify it. The option *is-shared-nss* is a boolean flag to determine if the nss is shared among Network Slice Instances that use this Netslice Subnet. Moreover, we provide an optional description, and we set the reference to the Network Service that form the netslice subnet in the field *nsd-ref*.

Finally, we need to define the connections among the *netslice-subnets*. We can define the connections in section *netslice-vld*:

Finally, it is defined the connections among the `netslice-subnets` in section `netslice-vld` as is shown below:

```yaml

netslice-vld:

            nsd-connection-point-ref: nsd_cp_data1

```

Having the network slice template ready, we need to upload the resources to the OSM before upload the network slice template. You can use the following commands to check the vnfds nsds and upload the packages to OSM:

Having the network slice template ready is needed to onboard the resources to the OSM before upload the network slice template. The following commands help you to onboard packages to OSM:

- **VNF package:**

  - List Virtual Network Functions Descriptors

  - Show if *slice_hackfest2_nst* was uploaded correctly to OSM

    - `osm nst-show slice_hackfest2_nst`

With all resources already available in OSM, we can proceed to deploy the *slice_hackfest_nst*. Let's start with the help of the command to create a network slice instance:

With all resources already available in OSM, it is possible to create the Network Slice Instance (NSI) using the *slice_hackfest_nst*. You can find below the help of the command to create a network slice instance:

```text

osm nsi-create --help

  -h, --help          Show this message and exit.

```

To instantiate the network slice template we are going to use the command:

To instantiate the network slice template use the following command:

```text

osm nsi-create\

Where:

- `--nsi-name` is the name of our network slice Instance: **my_first_slice**

- `--nst-name` is the name of our network slice template: **slice_hackfest_nst**

- `--vim_account` is the default VIM account id or name for the deployment

- `--config`  is the configuration parameter we use for this slice. We want to attach the management network to an external network of the VIM to have access to the VNF deployed in the slice. In the `netslice-vld` list, we set that the `slice_vld_mgmt` will use the external network VIM in the key `vim-network-name`. It has to be replaced with the name of the external network of the VIM.

- `--nsi-name` is the name of the Network Slice Instance: **my_first_slice**

- `--nst-name` is the name of the Network Slice Template: **slice_hackfest_nst**

- `--vim_account` is the default VIM account id or name to be used by the NSI

- `--config` is the configuration parameter used for the slice. For example, it is possible to attach the NS management network to an external network of the VIM to have access to the VNF deployed in the slice. In this case, `netslice-vld` list, contains the name of the VLD **slice_vld_mgmt** used to attach the external network of the VIM by `vim-network-name` key.

We have two more commands to operate the slices instances.

The commands to operate the slice are:

- List Network Slice Instances

  - `osm nsi-list`

- Delete Network Slice Instance

  - `osm nsi-delete <nsi_name> or <nsi_id>`

The result of the deployment in Openstack will look like:

The result of the deployment in Openstack looks like:

![Network Slice Instance](assets/800px-hackfest_nsi.png)

![Network Slice Instance Openstack](assets/400px-slice_instance_openstack.png)

In the picture above, we can see three VNFs deployed in openstack connected to management openstack network `osm-ext` and also connected among them following the vlds described in the network slice template.

In the picture above, it is shown three VNFs deployed in OpenStack connected to management OpenStack network `osm-ext` and also connected among them, following the VLDs described in the network slice template.

### Sharing a Network Slice Subnet

In this section, we will create a new network slice template that uses the middle netslice subnet from the previous instantiation to add a new netslice-subnet connected via data2 VLD. The picture below defines the case we want to achieve.

To test the feature of sharing a network slice subnet, we create a new network slice template that uses the shared netslice subnet from the previous instantiation. The picture below shows the Network Slice Template.

![Sharing network slice subnet](assets/800px-shared_nst.png)

The network slice template used in this section is *slice_hackfest2_nst.yaml* and is available in the [resources](#resources) section.

The network slice template used for sharing a network slice subnet is *slice_hackfest2_nst.yaml* and it is available in the [resources](#resources) section.

```yaml

nst:

            nsd-connection-point-ref: nsd_cp_data

```

As you can see in the YAML above, this NST have 2 *netslice-subnet*, one with the flag *is-shared-nss* as true and the other one with the flag *is-shared-nss* as false. The *netslice-vlds* will connect the *slice_hackfest_middle_nsd* nss with management interface and data2 with the *slice_hackfest_nsd* via *nsd_cp_data*

 The YAML above contains 2 *netslice-subnet*, one with the flag *is-shared-nss* as true and the other one with the flag *is-shared-nss* as false. The *netslice-vlds* will connect the *slice_hackfest_middle_nsd* nss with management interface and data2 with the *slice_hackfest_nsd* via *nsd_cp_data*

To instantiate this network we will use the same command used previously but changing the `nst_name` to *slice_hackfest2_nst*:

To instantiate this network slice, we will use the same command used previously but changing the `nst_name` to *slice_hackfest2_nst*:

```text

osm nsi-create\

--config 'netslice-vld: [{ "name": "slice_vld_mgmt", "vim-network-name": <replace_vim_external_network> }]'

```

The result of the instantiation is shown in the picture below:

You can see the result of the instantiation in the picture below:

![shared nsi](assets/800px-hackfest_shared_nsi.png)

What would happens with the shared Network Slice Subnet and the second Network Slice Instance if we delete the first Network Slice Instance?

Let's make a try!

With the command `osm nsi-delete my_first_slice` we can delete the first Network Slice Instance. The result is that the middle Network Slice Subnet (shared) belongs to the NSI2, and is not deleted when NSI1 is deleted. All networks and services created for NSS middle are kept. In the picture below, you can see the result in Openstack and the logical result of the deletion of NSI1:

With the command `osm nsi-delete my_first_slice` we can delete the first Network Slice Instance. The result is that the middle Network Slice Subnet (shared) belongs to the NSI2, and it is not deleted when NSI1 is deleted. All networks and services created for NSS middle are kept. In the picture below, is shown the result in Openstack and the logical result of the deletion of NSI1:

![nsi1 deletion](assets/800px-nsi1_delete.png)

![nsi1 deletion openstack](assets/400px-nsi1_delete_openstack.png)

To remove the NSI2 you can do it with the command: `osm nsi-delete my_shared_slice`.

Further information you can find a good explanation and examples [in this presentation](http://osm-download.etsi.org/ftp/osm-6.0-six/8th-hackfest/presentations/8th%20OSM%20Hackfest%20-%20Session%206%20-%205G%20Network%20Slicing%20with%20OSM.pdf)

To remove the NSI2 run the command: `osm nsi-delete my_shared_slice`.

## Using Kubernetes-based VNFs (KNFs)