Re: [Teas] WG adoption poll: draft-contreras-teas-slice-controller-models-05

[LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>]

Hi Adrian

Thanks so much for your very detailed review of the draft. We will go through all your detailed comments in next version.

Let me just comment about your initial statement on the description of potential implementation and the consideration of internal interfaces.

As stated in the abstract and the introduction, the draft does not have the purpose of standardizing or constraining the implementation the IETF Network Slice Controller. Its primary intention is to describe how the different models being defined can interplay, and for that two main building blocks are considering, one related to the mapping of the technology agnostic IETF network slice service to resources as represented by NRPs, and the other related to the realization of the slice with technology specific approach.

The good work in TEAS is producing a number of models but it is yet needed a piece that could help to describe how all of them interplay, and also if some gaps could exist for completing all the process. So that is the actual purpose of digging a bit on those building blocks.

Respect to the fact if those building blocks could be implemented by different vendors, I do not have a clear answer. First, as said, the draft does not prelude if those should be the only building blocks to consider, nor if an actual NSC should be implemented in that way. But going to your comment, and talking in general (I mean not thinking only on the mapper and realizer building blocks), I guess that in some cases the full NSC functionality could require of some interworking between different modules from different vendors. For example, this could be the case of needing some technology-specific augmentations in the transition from the technology agnostic IETF Network Slice request to the technology-specific IETF Network Slice realization. Not all the vendors have a complete portfolio covering all the technologies, so that could be an scenario where integrating modules form different vendors could be necessary for getting the full NSC functionality (again I’m talking in a generic way, not referring to the mapper and realizer building blocks in the draft).

From this discussion about internal interfaces, also from other colleagues in the list, something is concerning me. If we do not want to deal with internal interfaces, then what is the sense of standardizing models like the ones related to NRP?

Thanks again for your comments, we will go through them after the poll result.

Best regards

Luis

De: Teas <[e-mail]> En nombre de Adrian Farrel
Enviado el: domingo, 9 de julio de 2023 2:51
Para: 'Vishnu Pavan Beeram' <[e-mail]>; 'TEAS WG' <[e-mail]>
CC: 'TEAS WG Chairs' <[e-mail]>
Asunto: Re: [Teas] WG adoption poll: draft-contreras-teas-slice-controller-models-05

Hi,

Thanks for this draft. I reviewed it mainly to check for consistency
with the core slicing work, but obviously other things showed up.


I'm not thrilled to have a document that describes a potential
implementation of a component and that exposes internal interfaces. I
don't think there is any intention that the Mapper and Realizer would be
implemented by different vendors, so this is not an external interface
that you are describing. While the text is at pains to say that no
attempt is being made to standardise how the NSC is implemented, I don't
understand why it is necessary to publish any description of any
potential internal structure.

I do support the discussion of the external interfaces of the NSC and
the functional responsibilities of the NSC.

All things considered, I don't object to adopting this document, but
I'm not enthusiastic.

Best,
Adrian

===

Jeff doesn't work for Microsoft any more.

---

Can we please think hard before adopting I-Ds with too many authors.
The later we push the decision on reducing the front page names, the
harder it gets.

---

idnits warns about the references section (are all the reference
normative?) and a non-ASCII character (Section 3, line 2).

---

Document title and the section headings need to be in Title Case

---

1.

   Among the capabilities mentioned, connectivity of different parts of
   a network slice with particular performance characteristics play a
   central role.

I struggled to make sense of this.
- "mentioned" where and by whom?
- "parts of a network slice" means what?

---

Figure 1 is not a prefect copy from draft-ietf-teas-ietf-network-slices

---

Section 2 describes the customer view of the slice and says "It can
include the slice topology".  I think that "topology" is probably the
wrong word because it implies a network and transit nodes etc. Maybe
you should talk about a "connectivity matrix".

---

I think it would be nice if Figure 2 showed the "provider's view" (b)
exposed horizontally. That is, a human operator, wishing to see what
slices are being provided by the network and how they are realized,
would access that information using the models defined at that
interface.

In my opinion, this is a better use of those models that stating they
are used between two hypothetical internal sub-components.

---

5.

s/draft/document/

---

5.

   However,
   anything prevents that these modules could be separated components,
   communicating through standard protocols (i.e., not as an internal
   communication to the IETF NSC).

s/anything/nothing/
s/separated/separate/

The Security Considerations section is a really odd place to introduce
that you could consider the Mapper and Realizer as separate components
contrary to what the rest of the document says.

From: Teas <[e-mail]<mailto:[e-mail]>> On Behalf Of Vishnu Pavan Beeram
Sent: 04 July 2023 20:42
To: TEAS WG <[e-mail]<mailto:[e-mail]>>
Cc: TEAS WG Chairs <[e-mail]<mailto:[e-mail]>>
Subject: [Teas] WG adoption poll: draft-contreras-teas-slice-controller-models-05

All,

This is start of a *two* week poll on making
draft-contreras-teas-slice-controller-models-05 a TEAS working group document
[https://datatracker.ietf.org/doc/html/draft-contreras-teas-slice-controller-models-05].

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 July 19th.

Thank you,
Pavan, Lou and Oscar

________________________________

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 confidential and privileged 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
________________________________

Le informamos de que el responsable del tratamiento de sus datos es la entidad del Grupo Telefónica vinculada al remitente, con la finalidad de mantener el contacto profesional y gestionar la relación establecida con el destinatario o con la entidad a la que está vinculado. Puede contactar con el responsable del tratamiento y ejercitar sus derechos escribiendo a [e-mail]<mailto:[e-mail]>. Puede consultar información adicional sobre el tratamiento de sus datos en nuestra Política de Privacidad<https://www.telefonica.com/es/telefonica-politica-de-privacidad-de-terceros/>.

We inform you that the data controller is the Telefónica Group entity linked to the sender, for the purpose of maintaining professional contact and managing the relationship established with the recipient or with the entity to which it is linked. You may contact the data controller and exercise your rights by writing to [e-mail]<mailto:[e-mail]>. You may consult additional information on the processing of your data in our Privacy Policy<https://www.telefonica.com/en/wp-content/uploads/sites/5/2022/12/Telefonica-Third-data-subjects-Privacy-Policy.pdf>.

Informamos que o responsável pelo tratamento dos seus dados é a entidade do Grupo Telefónica vinculada ao remetente, a fim de manter o contato professional e administrar a relação estabelecida com o destinatário ou com a entidade à qual esteja vinculado. Você pode entrar em contato com o responsável do tratamento de dados e exercer os seus direitos escrevendo a [e-mail]<mailto:[e-mail]>. Você pode consultar informação adicional sobre o tratamento do seus dados na nossa Política de Privacidade<https://www.telefonica.com/es/politica-de-privacidade-de-terceiros/>.