Re: [Teas] draft-liu-teas-transport-network-slice-yang-06

[[e-mail]]

Hi Aihua, all,

As this draft is scheduled for the IETF#118 meeting, I checked the latest version to see whether the new text clarifies the issues I raised in the past. My conclusion is that I doesn’t, unfortunately.

Specifically, I’m still having troubles to position this effort compared to what can be achieved by combining https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slice-nbi-yang-08#name-ietf-network-slice-service-o and https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-vn-yang-20#name-type-2-vn.

I’m sure you have answers to why another module is needed compared to what can be achieved using draft-ietf-teas-actn-vn-yang. Writing them down would greatly help readers like me.

So please, let’s have that discussion before the session. Thanks.

Cheers,
Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : jeudi 29 juin 2023 08:53
À : 'Aihua Guo' <[e-mail]>
Cc : [e-mail]; TEAS WG <[e-mail]>; JACQUENET Christian INNOV/NET <[e-mail]>
Objet : RE: draft-liu-teas-transport-network-slice-yang-06

Hi Aihua, Sergio, Italo, and all,

Many thanks for this clarification. This is really helpful to position this work vs. other pieces. It would be useful to reflect the various options you discussed below in the draft itself before diving into the proposed model itself.

As you position this work as defining customized topology (with constraints), you may also wany to motivate why using draft-ietf-teas-actn-vn-yang is not sufficient.


FWIW, please note that I have the following about your draft in https://datatracker.ietf.org/doc/html/draft-boucadair-teas-ietf-slicing-overview-01#name-network-slice-topology-2:

==
The need for such a model is yet to be justified as the current scope is redundant with what can be already achieved using the SAP model (Section 5.3.1).
==

Will look into your new version when it is out and see whether/how to update the above assessment.

Thank you.

Cheers,
Med

De : Aihua Guo <[e-mail]<mailto:[e-mail]>>
Envoyé : jeudi 15 juin 2023 21:29
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc : [e-mail]<mailto:[e-mail]>; TEAS WG <[e-mail]<mailto:[e-mail]>>; JACQUENET Christian INNOV/NET <[e-mail]<mailto:[e-mail]>>
Objet : Re: draft-liu-teas-transport-network-slice-yang-06

Hi Med,

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

First of all, on the terminologies we are using:
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, helping the provider to indicate allocatable resources for 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.

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

Please see more comments on your points below.

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

On Wed, Apr 5, 2023 at 10:47 AM <[e-mail]<mailto:[e-mail]>> wrote:
Hi Authors,

Thank you for writing this document.
[AG] Thank you 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 is intended 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, adding SLO/SLEs for each topological construct, e.g. topology, nodes, links, termination points. The model also reuses the same SLO/SLEs for the topology constructs as for the network slice connections defined in draft-ietf-teas-ietf-network-slice-nbi-yang.
I think 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] IMHO 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 with respect to the model defined in this draft.
Furthermore, I think there are a few options for defining such a model for abstract topologies. One option, like what you suggested, is 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 make it a complete topology. However, it appears unclear to me why augmenting a model that was born for another scope when existing models such as the TE topology (RFC8795) (or a proper profile) can be used for the same purpose without the need of any particular update.

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 are updating the draft text and incorporating your comments into the next revision of the draft. Meanwhile please see a detailed response to your points here<https://github.com/aguoietf/ietf-network-slice-topology/files/11708426/draft-liu-teas-transport-network-slice-yang-06-rev.Med-sb.docx>:


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.
____________________________________________________________________________________________________________
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.