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

[Eric Gray <[e-mail]>]

That is a reasonable suggestion.  Thanks!

--
Eric

From: Xufeng Liu <[e-mail]>
Sent: Thursday, March 12, 2020 4:18 PM
To: Eric Gray <[e-mail]>
Cc: [e-mail]; Wubo (lana) <[e-mail]>om>; Dongjie (Jimmy) <[e-mail]>om>; Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>om>; Jari Arkko <[e-mail]>om>; John E Drake <[e-mail]>
Subject: Re: [Teas-ns-dt] Pull-request #8: Reza’s proposed text addition to the controller section
Importance: High

Hi Eric,

On Thu, Mar 12, 2020 at 10:51 AM Eric Gray <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, March 5, 2020 9:36 AM
To: Eric Gray <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Wubo (lana) <[e-mail]<mailto:[e-mail]>>; Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>; Jari Arkko <[e-mail]<mailto:[e-mail]>>; John E Drake <[e-mail]<mailto:[e-mail]>>
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=[e-mail]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/teas-ns-dt