Re: [Teas-ns-dt] Pull-request #9: Reza’s proposed text for Transport Slice Controller (TSC) Northbound Interface (NBI)

[Eric Gray <[e-mail]>]

Agree with Jari, completely.

Also, see additional comments below…

From: Teas-ns-dt <[e-mail]> On Behalf Of Jari Arkko
Sent: Sunday, February 23, 2020 5:04 PM
To: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>
Cc: [e-mail]
Subject: [Teas-ns-dt] Pull-request #9: Reza’s proposed text for Transport Slice Controller (TSC) Northbound Interface (NBI)

This email concerns Pull-request #9: Reza’s proposed text for
Transport Slice Controller (TSC) Northbound Interface (NBI).  This
review is again a personal review, not holding any hats, just
providing my opinion.

I think this is useful material as well, thank you Reza! I do think
though that many of the details of the way that the NBI  data model
is designed are probably worth placing in the actual NBI document
later. The framework needs to talk about what the NBI is and what
we expect out of it, and some of the general issues, but it does
not need to detail, e.g., data model structure or make detailed
design decisions about specific ways of accomplishing those
goals.

> As shown in Figure 1, the Transport Slice Controller NBI interfaces
> provides the abstaction of the transport slices to the higher level
> system.  It simplifies the automation, assurance and optimization of
> transport slices by hiding all the complexity of the transport slice
> for realization and monitoring.

I think I'd write this as

    The Transport Slice Controller provides a Northbound Interface (NBI)
    that allows consumers of network slices to request and monitor
    transport slices. The consumers operate on abstract transport slices,
    with the details related to their realisation hidden.

> The main characteristics of these
> new interfaces are:
>
> * These interfaces allow a request and response about resources.
>   It should not allow negotiation, as this would be complex and not
>   have a clear benefit

This is too low-level detail for this document. Lets design the NBI in
another document, later. I also don't know yet if the request-response
or negotiation are the right technical choices.  But we don't need to
decide that in this document.

> * The provider of these interfaces is the higher layer sytem which
>   needs to create an E2E network slice.  The provider of this
>   interface is the lower layer netowork controllers which provide
>   the realization of the connectivities (i.e. transport slice).

I would like to remove all discussion of the e2e slices and slicing
from our documents. It is distracting, and ultimately leads to a need
to having to detail how 3GPP systems work. It is also not the only
case for slicing, as someone may need slices even when  they are
not constructing an end-to-end  slice. We from the IETF provide
a transport slice, end of story :-)

> * These interfaces are needed in industry to achieve true standard
>   based automation of E2E network slices.  It provides technology-
>   agnostic intent-based interfaces to the higher level system (note
>   that as an example, these interfaces are similar to interfaces
>   defined by 3GPP for 5G RAN and 5G Core slices)

Mumble. I'd say too low level detail, plus maybe the language
on automation is not as technical as it should be in this type of
document.

> * These interfaces are independent of type of network functions or
>   services which needs to be connected, i.e. it is independent of
>   any specific repository, software usage, protocol, or platform
>   which realizes the physical or virtual network functions.

This is ok.

> * These interfaces standardizes a way to learn about what resources
>   are available in the network which impact the creation of the
>   transport slices

Mumble. An implementation detail in the controller and/or southbound
issue and/or general network management issue. I'd say not for our
document.

> * These technology independent interfaces simplify the
>   creation/modification/deletion of the transports slices by
>   describing it in a standard way along with all the endpoints that
>   compose a transport slice, their properties, attributes and their
>   SLO requirements

We already said this, in other words.

> * These interfaces provide capabilities for transport slice
>   monitoring and analytics which means that these interface allow
>   enabling/disabling the collection of the transport slices
>   telemetry, assurance and Threshold Crossing Alert (TCA) data and
>   providing them to the higher level system

I don't think we should talk about analytics or other functions that
might be performed on top either the NBI or the controller.

EG > Text relating to “optimization” or “analytics” definitely has no place in this document.

> * These interfaces provide capabilities for optimization of the
>   transport slices.  Since the E2E network slices are dynamic in
>   nature, it is important to make sure the transport slice SLOs are
>   valid and in case any SLO violation, the transport slice
>   controller performs the closed-loop action and inform the higher
>   layer system for the violation and closed-loop action.  These
>   interfaces allow this fucntionality.

I think this is again outside scope.

EG > Text relating to “optimization” or “analytics” definitely has no place in this document.

> * These interfaces allows binding and association between
>   "Transport slices" to "Other Slices"

I don't understand. What slices are you talking about?

EG > My interpretation of what is meant here makes me feel bleak.  The function of a “higher-level” entity should be to figure out how the request Transport Slice fits into a larger context (whether end-to-end, or otherwise); this is definitely not the role reasonable people should expect the TSC to fill.

> * These interfaces complements various IETF services, tunnels, path
>   models by providing an abstract layer on top of these models

Ok, good!

> # Transport Slice Controller NBI high level data model
>
> Figure 3 shows the high level data model of TSC NBI interfaces.  The
> aim is to illustate the main building block of the data model.  For
> complete NBI YANG model see rrrrr (author's note: This is the new
> draft on NBI YANG):
>
>    |----------------------------------------------------------------|
>    | module: transport-slice                                        |
>    | +--rw transport-slice                                          |
>    |   +--rw transport-slice-info                                   |
>    |    +--rw ts-id                                                 |
>    |      +--rw ts-name                                             |
>    |      +--...                                                    |
>    |    +--rw e2e-network-slice-info [ns-id]                        |
>    |       +--rw list of e2e network slice id                       |
>    |       +--rw customer (aka tenant)                              |
>    |       +--rw service type (e.g. CCTV, infotainment etc)         |
>    |       +--...                                                   |
>    |    +--rw transport-slice-group* [tsg-id]                       |
>    |       +--rw tsg-id                                             |
>    |          +--...                                                |
>    |       +--rw endpoint* [endpoint-id]                            |
>    |          +--rw endpoint-id                                     |
>    |          +--...                                                |
>    |       +--rw connection-link* [link-id]                         |
>    |          +--rw link-id                                         |
>    |          +--rw endpoint-A                                      |
>    |          +--rw endpoint-B                                      |
>    |          +--...                                                |
>    |       +--rw transport-slice-policy* [policy-id]                |
>    |          +--rw policy-id                                       |
>    |          +--rw policy-type (e.g. slo-policy, selection-policy, |
>    |                                  assurance-policy)             |
>    |          +--...                                                |
>    |----------------------------------------------------------------|
>
>       Figure 3: Transport Slice Controller NBI high-level data model

Way too detailed for this document. Lets save this for draft-ietf-teas-dt-nbi-00  :-)

> Refering to Figure 3, the proposed TSC NBI data model should include
> the following building blocks:
>
> * transport-slice-info: It contains information  related to transport
> slice such as transport slice name, transport slice ID etc.
>
> * e2e-network-slice-info: A list of all E2E network slices mapped to
>   a transport slice.  Note that transport slice to E2E network slice
>   is a one-to-many mapping, i.e. one transport slice can be used
>   inside more that one e2e network slice
>
> * transport-slice-group: A transport slice is a set of transport-
>   slice-groups where each of them contains a set of distint
>   connections.  Each transport-slice-group contains:
>
>       * list of endpoints: A transport slice comprises a set of
>         connection among various endpoints.  These attributes
>         specify the endpoint in a generic fashion. The possible
>         attributes of the endpoint could be IP address, node name,
>         domain ID and termination points etc. The details will be
>         provided in TSC NBI YANG draft.
>
>       * list of connection-links: These are the list of connections
>         between endpoints.
>
>       * list of transport-slice-policies: The request from TSC NBI
>         to create the transport slices will have optional and mandatory
>         policies, which specify the desired "transport slice SLO" along with
>         information on monitorig and mapping functions. This draft
>         proposes three types of transport slice policies to be supported.
>         The details of these policies shall be provided in TSC NBI YANG draft:
>
>              * transport-slice-slo-policy: This is a mandatory policy, which
>                represents in a generic and technology-agnostics way the required
>                "transport slice SLO" needed to realize a transport slice.
>                It is defined per transport-slice-group and contains the
>                bounded latency, bandwidth, reliability, security etc.
>
>              * transport-slice-selection-policy: This is an optional policy.
>                In some deployment, the higher level system might want to influence
>                the transport slice controller (TSC) on how to realize a transport
>                slice by providing some information regarding the type of technologies
>                and tunnels.
>
>              * transport-slice-assurance-policy: This is an optional policy.
>                The higher level system might want to influence the transport slice
>                controller for transport slice assurance on how to perform
>                monitoring, analytics and optimization.  This policy will be used
>                and contains, the type of assurance needed, time interval,
>                how often inform the higher level system etc.

Some of this is ok, but should be described at an abstract level, some
of it is way beyond the scope of this document.  We're not defining
the NBI here.

In conclusion, I'd suggest to keep the following text:

    The Transport Slice Controller provides a Northbound Interface (NBI)
    that allows consumers of network slices to request and monitor
    transport slices. The consumers operate on abstract transport slices,
    with the details related to their realisation hidden.

    The NBI is independent of type of network functions or
    services which needs to be connected, i.e. it is independent of
    any specific repository, software usage, protocol, or platform
    which realizes the physical or virtual network functions.

   The NBI complements various IETF services, tunnels, path
   models by providing an abstract layer on top of these models.

   The NBI is based on protocol mechanisms and information
   passed over those mechanisms to convey the desired
   transport slices and their status. The information is expected
   to be represented as a well-defined data model, and should
   include at least endpoint and connectivity information,
   SLO specification, and status information.