Re: [Teas-ns-dt] Text Proposal

[Eric Gray <[e-mail]>]

Reformatted…  ☹

From: Eric Gray <[e-mail]>
Sent: Tuesday, June 30, 2020 10:31 AM
To: teas-ns-dt <[e-mail]>
Cc: Eric Gray <[e-mail]>om>; teas-wg/teas-ns-dt <[e-mail]>
Subject: Re: Text Proposal

Some notes on the text below:
-             I made some minor mods to the figure (which may need to be retrofit into the corresponding figure in the definitions draft (mostly we use “Network Controller” in the figure but refer to “Transport Network Controller” in the text - I checked and the same is true in the definition draft).
-             I replaced the “arrow characters” (“A” and “V”) with the ones I usually use (“^” and “v”) as I heard at least one person who seemed to be confused by the “symbols” “A” and “V” in the figure.
-             The figure is essentially otherwise as we had agreed it should be in the meeting yesterday.

I saw comments from Kiran, but I am uncertain what Kiran thinks I should do about them, especially given that at least part of the comments were about stuff that is out of scope anyway...




On Jun 30, 2020, at 10:07 AM, Eric Gray wrote:

   Abstraction and Control of TE Networks (ACTN - [RFC8453]) is an
   example of similar IETF work.  ACTN defines three controllers to
   support virtual network (VN) services -

   *  Customer Network Controller (CNC),

   *  Multi-Domain Service Coordinator (MDSC) and

   *  Provisioning Network Controller (PNC).

   A CNC is responsible for communicating a customer's VN requirements.

   A MDSC is responsible for multi-domain coordination, virtualization
   (or abstraction), customer mapping/translation and virtual service
   coordination to realize the VN requirement.  Its key role is to
   detach the network/service requirements from the underlying
   technology.

   A PNC oversees the configuration, monitoring and collection of the
   network topology.  The PNC is a underlay technology specific
   controller.

   While the ACTN framework is a generic VN framework that is used for
   various VN service beyond the transport slice, it is still a suitable
   basis to understand how the various controllers interact to realize a
   transport slice.


   One possible mapping between the transport slice, and ACTN,
   definitions is as shown in Figure 1 below.

       +-------------------------------------+
       |             Customer                |  |
       +-------------------------------------+
                         ^                      |     ACTN
                         |                         Terminology
                         v                      |  and Concepts
       +-------------------------------------+
       |      A highter level system         |  |   +-----+
       |(e.g. e2e network slice orchestrator)| ===> | CNC |
       +-------------------------------------+  |   +-----+
                         ^                             ^
                         | TSC NBI              |      | CMI
       +-------------------------------------+  |   +------+
       |      Transport Slice Controller     | ===> | MDSC |
       +-------------------------------------+  |   +------+
                         ^                             ^
                         | TSC SBI              |      | MPI
                         v                             v
       +-------------------------------------+  |   +-----+
       |   Transport Network Controller(s)   | ===> | PNC |
       +-------------------------------------+  |   +-----+

                Terminology/Concepts            |
               Used in this Document
                                                |

                              Figure 1

   Note that the left-hand side of this figure comes from Transport
   Slice Definition ([I-D.nsdt-teas-transport-slice-definition]).

   The TSC NBI conveys the generic transport slice requirements.  These
   may then be realized using an SBI.

   As per [RFC8453] and [I-D.ietf-teas-actn-yang], the CNC-MDSC
   Interface (CMI) is used to convey the virtual network service
   requirements along with the service models and the MDSC-PNC Interface
   (MPI) is used to realize the service along network configuration
   models.  [I-D.ietf-teas-te-service-mapping-yang] further describe how
   the VPN services can be mapped to the underlying TE resources.


   The Transport Network Controller (TNC) is depicted as a single block,
   analogous to the Provisioning Network Controller (in this example).
   In the ACTN framework, however, it is also possible that the TNC
   function is decomposed into MDSC and PNC - that is, the TNC may
   comprise hierarchy as needed to handle the multiple domains and
   various underlay technologies, whereas a PNC in ACTN is intended to
   be specific to at most a single underlay technology and (likely) to
   individual devices (or functional components).

   Note that the details of potential implementations of everything that
   is below the TSC in Figure 1 are out of scope in this document -
   hence the specifics of the relationship between TNC and PNC, and the
   possibility that the MDSC and PNC may be combined are at most
   academically interesting in this context.  Another way to view this
   is that, in the same way that ACTN might combine MDSC and PNC, the
   TSC might also directly include TNC functionality.

   [RFC8453] also describes TE Network Slicing in the context of ACTN as
   a collection of resources that is used to establish a logically
   dedicated virtual network over one or more TE networks.  In case of
   TE enabled underlying network, ACTN VN can be used as a base to
   realize the transport network slicing by coordination among multiple
   peer domains as well as underlay technology domains.

   Figure 1 shows only one possible mapping as each ACTN component (or
   interface) in the figure may be a composed differently in other
   mappings, and the exact role of both components and subcomponents
   will not be always an exact analogy between the concepts used in this
   document and those defined in ACTN.

   This is - in part - shown in a previous paragraph in this section
   where it is pointed out that the TNC may actually subsume some
   aspects of both the MDSC and PNC.

   Similarly, in part depending on how "customer" is interpreted, CNC
   might merge some aspects of the higher level system and the TSC.  As
   in the TNC/PNC case, this way of comparing ACTN to this work is not
   useful as the TSC and TSC NBI are the focus on this document.