Re: [Teas-ns-dt] Alignment between definition and framework drafts

[Eric Gray <[e-mail]>]

As there has been no discussion or disagreement on the proposed change below, I have gone ahead and made the suggested changes.

Also, as an action item out of the last conference call, I have renamed the section "Requirements" as "Transport Slice Objectives."  I also made one further change to the last paragraph; the prior wording refers to an example of  "additional requirements" (even though the document provides no other requirements) from the enhanced VPN draft.

I have removed "additional" in that paragraph.

I have pushed the changed files to our GitHub repository.

As a separate action, I will be posting the revised version as a "-02" draft, and updating the GitHub repository accordingly (i.e. - creating an initial "-03" version of both "Markdown" and ".txt" files, and adding a target to the Makefile to build XML and Text from the "Markdown" for this version).

--
Eric

From: Teas-ns-dt <[e-mail]> On Behalf Of Eric Gray
Sent: Friday, March 20, 2020 2:16 PM
To: [e-mail]
Cc: teas-wg/teas-ns-dt <[e-mail]>
Subject: [Teas-ns-dt] Alignment between definition and framework drafts

Folks,

The following text was "flagged" in the -00 version of the framework draft submitted to the ID repository as needing some work to align with the definition draft:

   ** Align with definitions draft **

   The users of transport slices are:

   *  The management system or other application that creates and
      manages them.

   *  The applications and components wishing to use these slices.

   Transport users are served by the system that can build transport
   slices, as follows:

   *  A controller takes requests from a management system or other
      application, which are then communicated via an abstracted
      northbound interface.  This interface transmits data objects that
      describe the needed transport slices in terms of topology and
      service level objectives (SLO).

   *  These requests are assumed to be translated by one or more
      underlying systems, which establish specific transport slice
      instances, using specific implementation techniques (such as IP
      and MPLS) implemented on top of the underlying network
      infrastructure.

The reason for this is that definition draft already defines "Customer" and "Transport
Slice Controller" - as well as North and South Bound Interfaces.

Also, this text has the issue that it seems to describe the interaction between a user
and the transport slice instances that they use as taking place in  only one direction.

I suggest replacing all of the text in question with the following:

"The Transport Slice Definition draft <ref> defines the role of a Customer (or User)
 and a Transport Slice Controller.  That draft also defines a TSC Northbound Interface
 (NBI).

"A transport slice user is served by the Transport Slice Controller (TSC), as follows:

* The TSC takes requests from a management system or other application, which are
   then communicated via an NBI.  This interface carries data objects the transport slice
   user provides, describing the needed transport slices in terms of topology, applicable
   service level objectives (SLO), and any monitoring and reporting requirements that
   may apply.  Note that - in this context - "topology" means what the transport slice
   connectivity is meant to look like from the users perspective; it may be as simple as
   a list of mutually (and symmetrically) connected end points, or it may be complicated
   by details of connection asymmetry, per-connection SLO requirements, etc.

* These requests are assumed to be translated by one or more underlying systems, which
   are used to establish specific transport slice instances on top of an underlying network
   infrastructure.

* The TSC maintains a record of the mapping from user requests to slice instantiations, as
   needed to allow for subsequent control functions (such as modification or deletion of the
   requested slices), and as needed for any requested monitoring and reporting functions."

--
Eric