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

Hi Eric,

On Thu, Mar 12, 2020 at 10:51 AM Eric Gray <eric.gray@ericsson.com> wrote:

> Xufeng,
>
>
>
>               So, what we are trying to say is that some information (we
> say “details”) could be provided between the Transport Slice consumer and
> the TSC via an NBI.
>
>
>
>               That statement is intended as a high-level summary and –
> because we are not defining the “details” of the NBI in this document – the
> actual details are (of course) out of scope (this is pretty much a
> tautology; it would be curiously weird, actually, to describe the details
> and then say that describing the details is out of scope).
>
Right. That is my feeling. Replacing one of these "details" would be better.

>
>
>               Do you have any suggestion for how we could make this
> clearer at the intended level, and without providing information we do not
> intend to provide?
>
Maybe using "the applied configuration, selected policies, and operational
state", or something like that. Like mentioned, anything other than
"details" would sound better.

>
>
>               If you do have a proposal that folks can get behind, I would
> be happy to put it in for the “-01” version…
>
>
>
> --
>
> Eric
>
>
>
> *From:* Xufeng Liu <xufeng.liu.ietf@gmail.com>
> *Sent:* Thursday, March 5, 2020 9:36 AM
> *To:* Eric Gray <eric.gray@ericsson.com>
> *Cc:* teas-ns-dt@ietf.org; Wubo (lana) <lana.wubo@huawei.com>om>; Dongjie
> (Jimmy) <jie.dong@huawei.com>om>; Rokui, Reza (Nokia - CA/Ottawa) <
> reza.rokui@nokia.com>gt;; Jari Arkko <jari.arkko@ericsson.com>om>; John E Drake
> <jdrake@juniper.net>
> *Subject:* Re: [Teas-ns-dt] Pull-request #8: Reza’s proposed text
> addition to the controller section
> *Importance:* High
>
>
>
> 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=
> 40ericsson.com@dmarc.ietf.org> 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
> Teas-ns-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/teas-ns-dt
>
>