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

[Jari Arkko <[e-mail]>]

This email concerns Pull-request #8: Reza’s proposed text addition to
the controller section. This review is again a personal review, not
holding any hats, just providing my opinion.

This is overall good text and relatively ready for inclusion.

I really liked the way that the section explained not just
the initial mapping but the mapping of telemetry etc. Good work!

There are some places where one can cut a bit unnecessary text, and a few
sentences where a more matter-of-fact style would work better in an
IETF document. I also think we need to be careful in not making the
controller section too long. It may be useful to add some specific
discussions elsewhere under the considerations section of the
framework document. And some discussions may not  be needed
in this document, in my opinion, such as the part about closed loop
optimizations - that's an important topic but we don't need to talk about
it to explain the framework. And I don't think we want to get to the
discussion of e2e slices. Transport slices are components of those,
but we can leave  it at that.

I also wondered how well the controller and mapping sections
complement each other; the editors should probably do a pass to ensure
that each section has the right content. Eric, John: feel free to move
text around if it fits better the other section!

I left a few TODOs in the text that I'd propose we use. There were
a couple of unclear points, mostly related to concepts not introduced
earlier and/or whose need to be included was unclear to me.

I'd use this text, edited from Reza's original:

# 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.

    The controller provides the following functions:

    * Provides a technology-agnostic NBI for creation/modification/
      deletion of the transport slices.  The attributes of this
      interface will be discussed in section sssss.  In summary, the
      API exposed by this NBI communicates the endpoints of the
      transport slice, transport slice SLO, various policies, and
      provides a way to monitor the slice.

    * Using the network abstract topology, it provides mechanism to find
      the Service endpoints (these are technology specific).
      (TODO: this seems unclear. What endpoints are these, are why
      are they different from endpoints discussed earlier?)

    * Provides "Mapping Functions" for realization of transport slices.
      In other words, it will use the mapping functions which map
      technology-agnostic NBI request to technology-specific SBIs.

    * On its southbound interface, the controller monitors Telemetry
      data (e.g.  OAM results, Statistics, States etc.) for all
      technology-specific services/paths/tunnels which are used to
      realize the transport slice.

    * Aggregates all the Telemetry data of underlying realization of a
      transport slice (i.e. services/paths/tunnels) and calculate the
      current "Transport Slice SLO" and exposes them to "Higher level
      system" through its NBI.  It also raises a notification in case
      the transport slice is out of SLO.

    * Provides the abstract network topology and in specific the "inter-
      domain" links between multiple network domains.
      (TODO: This is unclear, at least to me.)