Re: [Teas] WG Adoption poll - draft-nsdt-teas-ns-framework-05

Hi all,

Despite the fact that I acknowledge the value of the document, I feel more
discussion is needed before adoption. So I don't support the adoption at
this stage. Essentially,

Some reasons for that are:

.- The document states in sec. 3.2 that the NSC from one operator could
request IETF network slices to the NSC of another operator. This has
several implications in the NSC, and as such, should require more
discussion. For instance: (1) there could be different levels of
trustiness in the relationship among operators tat could imply different
levels of abstractions, not necessarily the same as with another kind of
customer/user, then open the door to the support of different kind of
information to be supported by the NBI; (2) the relationship between
operators could come via higher level systems instead, then relaxing /
modifying considerations such security, monitoring information, etc; (3)
having a direct relationship implies that one of the the SBI
implementations of a NSC should the same as the NBI, to support this
possibility; (4) there should be a common understanding / definition of the
abstractions between operators to express the services; etc

.- The document has a specific section for ACTN (sect. 4). In fact there
was some discussion on the list about this, reflecting the fact that
several interpretations could be provided for a mapping as the intended in
Figure 1, without a single mapping of entities between ACTN and the
intended framework. Besides that, a specific document describing the
applicability of ACTN to slicing
(draft-king-teas-applicability-actn-slicing) is now work-in-progress,
making the ACTN text in the framework document redundant with that other
document. In my view, sect. 4 is more confusing than clarifying, so I
prefer to remove it from the framework document, developing the
applicability of ACTN to slicing in that other dedicated document.

.- Section 3.5 described an initial workflow on the realization of IETF
Network Slices but it focuses only on provision. Other aspects of the IETF
Network SLice lifecycle are missing, and I think it would be important to
describe since this framework will become the basis for further
specifications of functionality of the IETF NSC. For instance, capability
exposure of the NSC (what happens if some SLOs cannot be provided?),
fulfillment, assurance, etc, are not included/discussed.

This is not an exhaustive review, this is just to remark the need of more
discussion for having clear the perimeter of the document before
progressing it into adoption, from my point of view.

Best regards

Luis

El jue, 4 feb 2021 a las 14:43, Vishnu Pavan Beeram (<vishnupavan@gmail.com>)
escribió:

> All,
>
> This is start of a *two* week poll on making
> draft-nsdt-teas-ns-framework-05 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 February 18th.
>
> Thank you,
> Pavan and Lou
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>

-- 
___________________________________________
Luis M. Contreras
contreras.ietf@gmail.com
luismiguel.contrerasmurillo@telefonica.com
Global CTIO unit / Telefonica