[Teas-ns-dt] FW: New Version Notification for draft-nsdt-teas-ns-framework-02.txt

[Eric Gray <[e-mail]>]

As seen below, and promised in the attached E-Mail, a "-02" version has been posted...

-----Original Message-----
From: [e-mail] <[e-mail]> 
Sent: Wednesday, March 25, 2020 4:27 PM
To: John Drake <[e-mail]>et>; Eric Gray <[e-mail]>om>; Eric Gray <[e-mail]>
Subject: New Version Notification for draft-nsdt-teas-ns-framework-02.txt
Importance: High


A new version of I-D, draft-nsdt-teas-ns-framework-02.txt
has been successfully submitted by Eric Gray and posted to the IETF repository.

Name:		draft-nsdt-teas-ns-framework
Revision:	02
Title:		Framework for Transport Network Slices
Document date:	2020-03-25
Group:		Individual Submission
Pages:		17
URL:            https://www.ietf.org/internet-drafts/draft-nsdt-teas-ns-framework-02.txt
Status:         https://datatracker.ietf.org/doc/draft-nsdt-teas-ns-framework/
Htmlized:       https://tools.ietf.org/html/draft-nsdt-teas-ns-framework-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-nsdt-teas-ns-framework
Diff:           https://www.ietf.org/rfcdiff?url2=draft-nsdt-teas-ns-framework-02

Abstract:
   This memo discusses setting up special-purpose transport connections
   using existing IETF technologies.  These connections are called
   transport slices for the purposes of this memo.  The memo discusses
   the general framework for this setup, the necessary system components
   and interfaces, and how abstract requests can be mapped to more
   specific technologies.  The memo also discusses related
   considerations with monitoring and security.

   This memo is intended for discussing interfaces and technologies.  It
   is not intended to be a new set of concrete interfaces or
   technologies.  Rather, it should be seen as an explanation of how
   some existing, concrete IETF VPN and traffic-engineering technologies
   can be used to create transport slices.  Note that there are is a
   rather large of these technologies, and new technologies or
   capabilities keep being added.  This memo is also not intended
   presume any particular technology choice.

                                                                                  


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--- Begin Message ---

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

--- End Message ---