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

[[e-mail]]

Hi Kenichi, all,

Thank you for clarifying the concerns you have with the NBI draft and for providing a concrete example. However:

* The network slice service is not necessarily a VN service. This needs to be further clarified in the slice framework draft.
* I do think that we need to keep in mind the role of the NBI and CLEARLY distinguish it from any technical realization of a network slice and also with narrow definitions of a slice (VN-specific with TE).
* A network slice service can be mapped, for example, to L3NM and/or L2NM without having to go through a VN mapping step (following, e.g., the framework in Section 3.1 of RFC8969).

* The “draft-wd-teas-ietf-network-slice-nbi-yang : actn-vn-yang ” structure you listed below may suggest that we could do the same exercise with L2VPN/L3VPN but we didn’t. We do have L3SM and L2SM because there are specifics to these services that are captured in these models. Slice service specifics should be captured in the NBI draft as well (I already raised this concern for the current NBI draft, but this does not prevent to adopt and work to fix that).
* Please note that draft-ietf-teas-actn-vn-yang says the following:

   The VN YANG model can be easily augmented to support the mapping of
   VN to the Services such as L3SM and L2SM as described in
   [I-D.ietf-teas-te-service-mapping-yang].

That text can be updated to cover the vn-slice mapping.

* One last point for which I support the nbi draft rather than relying upon the vn one is related to https://datatracker.ietf.org/ipr/4215/.

Thank you.

Cheers,
Med

De : Teas [mailto:[e-mail]] De la part de Ogaki, Kenichi
Envoyé : mercredi 15 septembre 2021 03:42
À : LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>; Vishnu Pavan Beeram <[e-mail]>; TEAS WG <[e-mail]>
Cc : TEAS WG Chairs <[e-mail]>
Objet : Re: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04


[[snip>>

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


_________________________________________________________________________________________________________________________

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.