Subject: [Netslices] Follow up clarifications on netslices discussion in OPS area

From: Kiran.Makhijani <[email-masked]>
Date: Thu, 16 Nov 2017 00:57:32 +0000

Hello all,

As a netslices proponent, I just watched the recording of the session (dint attend in person) and noticed that the essence of discussion was not about what we wanted to present, thus the lack of clarity remains. I thought we could start with some follow up discussions and clarifications.

Below is a summary of motivation behind drafts and answer to 2 questions asked on mic.

1. Information model is in fact augmented from i2rs-network topology model and is explained in the draft.  We (specifically Xavier) have worked hard to ensure YANG tree is well-aligned. I see NS as network of networks, using this model it is possible to attach different networks and construct topology. The inter-connect draft is about connecting different networks (segments of slices) together. The architecture draft will have end to end flow, any resource operations’ aggregation and related details for clarity. Use cases will give us guidance about the work to be done in the 3 drafts.

Some answers to comments made on mic:

2. @Nurit, about definition and end-to-end slice.
I think for having an end to end holistic view of slice, Info-model has everything to give end to end view of the network.

The information model is what operators will use to take a slice-service spec from tenant and interface with lower network level controllers/Network slice agents. It has a config-state for deploying a slice and operational-state to monitor and manage it. This is going to create mappings with physical/underlying network resources. This is why the work is directly relevant to IETF. Interface between tenant and this information model still needs to be addressed - may in architecture draft.

Regarding other organizations’ definition on slices; our definition is no different. It just helps align our documents better in current scope. We invite other Orgs to converge, bring in their requirements or solutions and have them covered here for common-interface and inter-operability. 2 great examples already covered are 5G-EX and ICN use cases.

3. @Jari: about “are data models implied only for slicing? how about VPN extensions?”
we have discussed this a lot, we think VPNs are more device/network specific, in that sense we try to see more from L3SM and L2SM can be deployed over a given network slice. Underneath operators could use VPNS at network-level. These drafts deliberately exclude data plane/low-level work. We want to limit the scope of work to just technology independent ops and mgmt.
a) "Network Slice as a Service" from operator’s view.
b) From an operator's view define standard communication interfaces and related data on it.
c) Reuse or augment existing technology-independent data models.

Once we know about your work, we could co-ordinate the 2 activities. If you think we should present this work in other WGs. Please suggest so.

Regardless, we request all to please review the drafts, and provide us feedback to make progress on these.

Regards,
Kiran