Justify using topology for network slices

Feedback from CCAMP WG: 2 10:04 10 Title: Framework and Data Model for OTN Network Slicing Draft: https://datatracker.ietf.org/doc/draft-ietf-ccamp-yang-otn-slicing/ Presenter: Aihua Guo Daniele Ceccarelli: (for model dependency) Option 1 is preferred. Bo Wu: Network Slice framework only talks SDP so far without including node/link defined in this Network Slice Topology, more discussion & clarification is needed. Aihua Guo : Okay.

The concern is about the justification of using topology for network slices. There is a reference in the NS framework document which has been referenced by ns-topo.

Additionally, the IETF Network Slice service customer might ask for some level of control of, e.g., to customize the service paths in a network slice.

For the requirements it is better for operators to voice on this option.

Also it is worth checking whether this requirement is applicable to transport network slicing only or is generic.

Optional to refer to the OIF document regarding the requirements for VTNS (?), IETF L1VPN framework and ACTN VN type 2

Feedback from TEAS WG: Offline discussion with Pavan : why not to use TE topology for ns-topo?

It would be helpful to add description about why TE topology or network topology is not sufficient for network slicing.

@aguoietf : about requirements , VTNS is the correct name . This is the related document from OIF https://www.oiforum.com/wp-content/uploads/2019/01/OIF-VTNS-01.0-IA.pdf IA OIF-VTNS-01.0 Virtual Transport Network Services Specification 1.0

In the VTNS definition , among other things it is clearly stated: ".... VTNS is built on the virtualization of transport network resources. The physical transport network resources are sliced and assigned usually with an abstract view to different users. The user request may include traffic matrix, Service Level Agreement (SLA), topology, Operation, Administration, and Maintenance (OAM), recovery requirements etc.

Comments from the last meeting (2023-05-04) Reza: an example of customized topology would be helpful, and how the customized topology relates to e.g. physical topology from both the customer and operator's perspective.

Clarify the definition of customized topology: what the customer defines, not what the operator exposes.
Use case for topology:
- Some customer constraints may be specified without a topology
- There are use cases when the customer is building a topology then use the topology for creating connections
Example of a customized topology

Summary of the discussion on customized topology:

There are certain use cases such as recursive network slicing and resource sharing between customer sites, that require customers to reserve resources and create network slices with connections expressing richer level of controls over a customized topology, rather than creating network slices with direct connections.
A customized topology is identified/defined by a network slice customer and is sent to the provider, whereas an abstract topology is a one exposed by the provider prior to the creation of network slices.
A customized topology contains a topology intent with necessary SLO/SLEs that express the customer’s resource reservation intent. The customer can create network slices in the future by specifying certain constraints such as inclusion, exclusion, detailed service path over the said customized topology.
The resource reservation for customized topology may be negotiated between the customer and provider. In this case, the data in the config data store represents the customer’s intent, and the data in the operational data store represents the intent committed by the provider and agreed upon by the customer after negotiation.
An abstract topology helps the provider indicate allocatable resources for network slices. This topology should contain information such as link or node capacity that is associated with the topological constructs.
The customer may map a customized topology to an abstract topology by providing the supporting nodes/links/TPs as defined in RFC 8345. The relationship between the customer and provider could be recursive: a high-level customer could request a customized topology from a lower-level provider, integrate the customized topology with its own topologies, and act as a provider to its own customer.

Therefore, our conclusion is that,

draft-liu focuses on the definition of customized topology used by the customer. It augments RFC 8345 by adding the SLO/SLEs for the topology constructs.
The modeling for abstract topology is outside the scope of draft-liu. Existing models or a new model can be defined separately for this purpose, as long as the model has both topological constructs with capabilities that describe the allocatable resources. For example, one could extend draft-sap with augments to the network topology, with resource capacity descriptions, and use it for exposing the abstract topology. Another option could be to use the TE topology (or a proper profile of the TE topology) for the same purpose.

underlay topology : a topology exposed by the network controller to the NSC and is kept internal to the NSC. :reference point (c) abstract topology: a topology exposed by the NSC to the customer: reference point (a) NRP topology: internal topology used by the NSC for mapping a network slice / network slice topology into internal realization. : reference point (b)

clarify customized topology vs. abstract topology. out of scope for abstract topology
do we need customized topology for network slicing? use some example to support the argument
why the new model for customized topology and not an existing one, e.g. TE topology or network topology

Draft response to Med:

Hi Med,

Thank you very much for your helpful reviews and thoughts. In the past month we the authors have been discussing the confusion around topologies used for network slicing, and came up with a few thoughts. Please see our response embedded below. Your feedback is much appreciated.

First of all, to align with the terminologies: Customized topology – a topology defined by the network slice customer and is sent to the network slice provider as a configuration input. Abstract topology – a topology exposed to the network slice customer by the provider prior to the creation of network slices NRP topology – a topology that is internal to the NSC to facilitate the mapping of network slices to underlying network resources A customized topology contains a topology intent with required SLO/SLEs to express the customer’s intent for resource reservation. Additionally, using customized topologies, the resource reservation may be negotiated between the customer and provider. In this case, the data in the config data store represents the customer’s intent, and the data in the operational data store represents the intent committed by the provider and agreed upon by the customer after negotiation.

With this draft we intend to propose a data model for defining customized topologies. The modeling for abstract topology is outside the scope of this draft.

Please find more comments to your points embedded below.

Thanks, Aihua, Sergio and Italo (on behalf of the co-authors)

On Wed, Apr 5, 2023 at 10:47 AM [mohamed.boucadair@orange.com](mailto:mohamed.boucadair@orange.com) wrote: Hi Authors,

Thank you for writing this document.

[AG] Thanks again for the valuable comments!

The document claims that this model is exposed to customers, while this is not justified. At least, the current text fails to motivate such a use. It is true that an NSC can use a customized topology for mapping purposes, but this is kept internal to the NSC and not exposed to a customer.

[AG] As indicated above, this draft intends to define a data model for customized topologies. We will improve the text in the next review to make this point clear.

This draft defines the model to augment the network topology model as defined in RFC 8345, with SLO/SLEs for each topological construct, e.g. topology, nodes, links, termination points. The model reuses the same SLO/SLEs for the topology constructs as for network slice connections defined in draft-ietf-teas-ietf-network-slice-nbi-yang.

I think here you are referring to the NRP topology and I agree that it is kept internal to the NSC. This draft does not intend to cover the modeling for neither the NRP topology nor the abstract topology.

Also, a network topology for slicing is readily available by setting the network type in draft-ietf-opsawg-sap to “network-slice”. I would expect to build missing pieces over the SAP topo rather than the current model in the draft. The draft should discuss why it is not sufficient to use the SAP topology.

[AG] If I understand correctly, draft-ietf-opsawg-sap helps the provider expose a list of SAPs to the customer prior to creating network slices and the customer may configure network slices with attachment circuits (ACs) pointing to the SAPs. If we call it a topology then it is defining an abstract topology per the above clarification, which serves different purposes as the model defined in this draft.

I think there exist a few options for defining such a model for abstract topologies. One option is like what you suggested, to extend draft-ietf-opsawg-sap with more attributes that represent the network capability/capacity rather than the customer's intent, as well as more topological constructs e.g. links that makes it a complete topology. Another option could be to just use existing models such as theTE topology (or a proper profile of the TE topology) for the same purpose.

We plan to add the above considerations to the next revision of the draft.

FWIW, a more detailed review can be found at:

pdf: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-liu-teas-transport-network-slice-yang-06-rev%20Med.pdf doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-liu-teas-transport-network-slice-yang-06-rev%20Med.doc

[AG] Much appreciate the detailed review. The authors will update the text and incorporate your comments in the next revision of the draft.

Cheers,

Med

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

draft-liu-teas-transport-network-slice-yang-06-rev Med-sb.docx

first step of reply to Med comments. Please review and ..go ahead

aguoietf / ietf-network-slice-topology

Justify using topology for network slices #10