Re: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04

[Tarek Saad <[e-mail]>]

Hi Kenichi/all,

I believe a vanilla IETF network slice service NBI data model (without VN data model augmentation) and that is aligned completely with the network slice definition terminology in draft-ietf-teas-ietf-network-slice-definition is preferrable. The authors of draft-ietf-teas-ietf-network-slice-definition have done a great/tedious job of defining and aligning terminology specific to network slicing.
I’m afraid creating another mapping (see extract from your email below – and this is not an exhaustive list) just to enable augmentation is not desirable and will lead to confusion and make situation worse.
For someone already using ACT framework, I understand a desire to extend it for network slicing, but forcing it on any customer/intent interface would IMO be undesrirable.

“

network-slices/network-slice : virtual-network/vn

network-slices/network-slice/ns-slo-sle-policy : vn-compute/input/path-constraints

network-slices/network-slice/ns-endpoints/ns-endpoint : access-point/ap/vn-ap

network-slices/network-slice/ns-connections : virtual-network/vn/vn-member
“

Regards,
Tarek

From: Teas <[e-mail]> on behalf of Ogaki, Kenichi <[e-mail]>
Date: Tuesday, September 14, 2021 at 9:52 PM
To: LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>, Vishnu Pavan Beeram <[e-mail]>, TEAS WG <[e-mail]>
Cc: TEAS WG Chairs <[e-mail]>
Subject: Re: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04

Hi Luis and All,


I believe we are on the same page, but the approach is a little bit different.

See a few comments inline[KO], please.



Thanks,

Kenichi

From: Teas <[e-mail]> On Behalf Of LUIS MIGUEL CONTRERAS MURILLO
Sent: Tuesday, September 14, 2021 4:29 AM
To: Vishnu Pavan Beeram <[e-mail]>; TEAS WG <[e-mail]>
Cc: TEAS WG Chairs <[e-mail]>
Subject: Re: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04

Hi all,

Yes/Support.

In my opinion an IETF Network Slice has special characteristics which can require a different model to express them. For instance, SLEs as the ones described by now in draft-ietf-teas-ietf-network-slices (i.e., isolation, security, etc) could imply different mappings later on existing models (or maybe different kind of augmentations, if the capabilities do not exist already) when choosing a specific technology or architectural framework for slice realization.


[KO] Agree.

An example of this could be the case of the VN as discussed in this thread. A slice requested with a Network Slice model with SLOs/SLEs as expected by slice customers could use e.g. the auto-creation capability at MDSC for later realization following ACTN architecture. Part of the SLEs could be maybe out of the VN model, but yet relevant for the slice realization. That is why an specific model could be needed.


[KO] We aren't saying the existing VN model can completely cover ietf network slice requirements as it is, but can enhance/augment to meet the requirements.

The question is what's the fatal problem for the VN model to *enhance/augment* to meet the requirements?

In terms of SLE, draft-wd-teas-ietf-network-slice-nbi-yang model definition is dealing with it as same as SLO, slo-sle-policy, then we also believe no big deal to augment as Sergio commented.

https://mailarchive.ietf.org/arch/msg/teas/5vQOGL-za1CwPgZb-pd9tyr09hE/



This is non-exhaustive list, but the two models have similar structures/objectives and we believe these are replaceable with enhancement/augmentation.



draft-wd-teas-ietf-network-slice-nbi-yang : actn-vn-yang

------------------------------------------------------------

network-slices/network-slice : virtual-network/vn

network-slices/network-slice/ns-slo-sle-policy : vn-compute/input/path-constraints

network-slices/network-slice/ns-endpoints/ns-endpoint : access-point/ap/vn-ap

network-slices/network-slice/ns-connections : virtual-network/vn/vn-member

Being said that, I would advocate for a consistent definition of draft-wd-teas-ietf-network-slice-nbi-yang and draft-liu-teas-transport-network-slice-yang since they represent two alternatives for slice request that could be expected to be found at the NBI of the Network Slice Controller (as described in draft-contreras-teas-slice-controller-models). In essence, align/integrate both models.


[KO] We agree with draft-liu-teas-transport-network-slice-yang or draft-busi-teas-te-topology-profiles concept should be introduced if te-topo model is closely tied to TE specific technology.


Best regards

Luis

De: Teas <[e-mail]> En nombre de Vishnu Pavan Beeram
Enviado el: viernes, 27 de agosto de 2021 17:07
Para: TEAS WG <[e-mail]>
CC: TEAS WG Chairs <[e-mail]>
Asunto: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04

All,

This is start of a *two* week poll on making
draft-wd-teas-ietf-network-slice-nbi-yang-04 a TEAS working group document.
Please send email to the list indicating "yes/support" or "no/do not support".
If indicating no, please state your reservations with the document. If
yes, please also feel free to provide comments you'd like to see
addressed once the document is a WG document.

The poll ends September 10th.

Thank you,
Pavan and Lou

________________________________

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