Re: [Teas-ns-dt] Pull-request #8: Reza’s proposed text addition to the controller section

[Xufeng Liu <[e-mail]>]

Hi Eric and All,

This section looks good to me. I have one minor comment in-line below.
Thanks,
- Xufeng

On Wed, Mar 4, 2020 at 6:23 AM Eric Gray <eric.gray=
[e-mail]> wrote:

> Based on Reza’s Pull #8 and the extensive discussion that followed, I plan
> to add the following text to the framework document:
>
>
>
> Transport Slice Controller (TSC)
>
> The transport slice controller takes abstract requests for
> transport slices and implements them using a suitable underlying
> technology. A transport slice controller is the key building
> block for control and management of the transport slice. It
> provides the creation/modification/deletion, monitoring and
> optimization of transport Slices in a multi-domain, a
> multi-technology and multi-vendor environment.
>
> In discussion in this document, a southbound interface (SBI)
> is used as a logical construct (that may or may not exist in
> practice) representing mechanisms used by the TSC in
> communicating with the underlying (abstract) network.
>
> A TSC northbound interface is needed for communicating
> details of a transport slice,
>
The word "details" here is vague to me. To what extent of the "details" the
NBI needs to communicate? what kind of details? The next sentence says "The
details for this NBI are not in scope", making the term here more
confusing. May I suggest some rewording? Maybe:
"the applied configuration, selected policies, and operational state"?

as well as providing information
> to a slice requester/consumer about transport slice status
> and performance. The details for this NBI are not in scope
> for this document.
>
> The controller provides the following functions:
>
>    - Provides a technology-agnostic NBI for creation/modification/
>    deletion of the transport slices. The API exposed by this NBI
>    communicates the endpoints of the transport slice, transport
>    slice SLO parameters (and possibly monitoring thresholds),
>    applicable input selection (filtering) and various policies, and
>    provides a way to monitor the slice.
>    - Determines an abstract topology connecting the endpoints of
>    the transport slice that meets criteria specified via the NBI.The
>
> TSC also retains information about the mapping of this abstract
>
> topology to underlying components of the transport slice as
>
> necessary to monitor transport slice status and performance.
>
>    - Provides "Mapping Functions" for the realization of transport slices.
>    In other words, it will use the mapping functions which:
>    - map technology-agnostic NBI request to technology-specific SBIs.
>    - map filtering/selection information as necessary to entities in the
>       underlay network.
>    - Via an SBI, the controller collects Telemetry data (e.g. OAM results,
>    Statistics, States etc.) for all elements in the abstract topology used
>    to realize the transport slice.
>    - Using the Telemetry data from the underlying realization of a
>    transport slice (i.e. services/paths/tunnels), evaluates the
>    current performance against transport slice SLO parameters and
>    exposes them to the transport slice consumer via the NBI. The
>    TSC NBI may also include a capability to provide notification in
>    case the transport slice performance reaches threshold values
>    defined by the transport slice consumer.
>
>
>
>
> --
> Teas-ns-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas-ns-dt
>