Re: [Teas-ns-dt] Pull-request #9: Reza’s proposed text for Transport Slice Controller (TSC) Northbound Interface (NBI)

[Eric Gray <[e-mail]>]

Reza,

              I agree that the TSC should be aware of the “real” underlying topology – which would include any relevant optimizations – to the extent that is possible.  Which is the rub;  every layer of networking is typically only able to view any lower layers as an “abstraction.”

              There are very good reasons why this tends to be true, and it would be absurdly ironic if we assume that the TSC presents an abstract view to some higher layer but is itself somehow entitled to a real view of the underlay network.

              As an example, a TSC might use TE parameters to choose a link for a certain communication channel.  Assuming what is really needed is (for instance) a certain minimum bandwidth, the value that a TSC might add is to monitor the status of ongoing TE parameter information to determine if there is a change that may impact the ability of the chosen link to continue to meet the required minimum bandwidth.

              What the TSC needs to know is that the TE parameters have changed.  We might benefit from knowing why they changed – for example, if the change was because the link is an aggregate of underlying links (think 100GE link composed of 4*25 GE) and one of the aggregated links fails – but the TSC may not be privileged to know that information.

--
Eric

From: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>
Sent: Saturday, February 29, 2020 12:51 PM
To: Wubo (lana) <[e-mail]>om>; Eric Gray <[e-mail]>om>; Jari Arkko <[e-mail]>om>; [e-mail]
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>
Subject: Re: Pull-request #9: Reza’s proposed text for Transport Slice Controller (TSC) Northbound Interface (NBI)
Importance: High

Thanks Bo and Eric.

In summary I agree with both.
It is better to explain what I mean with “closed-loop optimization” as I feel it needs more clarification. What I meant was that the TSC is aware of optimization that happened in the network for resources which are used to realize the transport slices (like all service/paths/tunnels). I did not meant that TSC is in the closed-loop for any type of optimization.  As indicated below, the delay introduced by TSC is unacceptable if TSC performs the closed-loop

In short, TSC should be fully aware of any “optimization” happened in the network for resources used to realize a transport slice. TSC is not responsible to do this as this is the responsibly of the “Network Controller” (refer to definition draft).

Eric, please replace the text with above explanation.

Cheers,
Reza

From: "Wubo (lana)" <[e-mail]<mailto:[e-mail]>>
Date: Saturday, February 29, 2020 at 4:37 AM
To: Eric Gray <eric.gray=[e-mail]<mailto:eric.gray=[e-mail]>>, Reza Rokui <[e-mail]<mailto:[e-mail]>>, Jari Arkko <jari.arkko=[e-mail]<mailto:jari.arkko=[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: Pull-request #9: Reza’s proposed text for Transport Slice Controller (TSC) Northbound Interface (NBI)

Hi Eric,

I agree with you on  the following analysis. Thank you for your detailed explanation.

Thanks,
Bo

发件人: Teas-ns-dt [mailto:[e-mail]] 代表 Eric Gray
发送时间: 2020年2月29日 0:44
收件人: Wubo (lana) <[e-mail]<mailto:[e-mail]>>; Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>; Jari Arkko <jari.arkko=[e-mail]<mailto:jari.arkko=[e-mail]>>; [e-mail]<mailto:[e-mail]>
主题: Re: [Teas-ns-dt] Pull-request #9: Reza’s proposed text for Transport Slice Controller (TSC) Northbound Interface (NBI)

Bo,

              Thanks for your inout to the discussion.

              One of the reasons I object to including “Analytics” and “Closed-Loop Optimization” is that I find it very dubious that either necessarily applies.

              Interestingly enough, I strongly suspect – based on previous discussions – that what Reza means by “closed-loop optimization” is the opposite of your interpretation; as I have come to understand it, Reza expects that (as a requirement to support automation), response to performance degradation are expected to be addressed directly by the TSC, without reliance on intervention of a higher-level system.

              I assume that Reza is referring to “optimization” of a “closed-loop control system” when he talks about “closed-loop optimization.”

              I have objections to referring to any form of “optimization” as a requirement in any IETF document, as “optimization” is typically an implementation characteristic and – as such – is unlikely to be completely detailed or fully explained in an IETF standard.  What we standardize is behavior/interactions required from an implementation – not better/best ways to do an implementation.

              If we want to require optimization, we have to be very specific about what we mean by optimization; what exactly is the goal to be met, etc.

              What might be more acceptable would be to indicate that the TSC is responsible for efficient use of transport resources in support of transport slices.  While this might be acceptable, this is essentially a semantic-free assertion along the lines of “everybody loves motherhood and apple pie.”

              However, the strongest objection I have is to the presumption that a TSC is a closed-loop control system; this is incorrect, by any definition of a closed-loop control system that I am aware of.  It might seem to be similar (to some) but, in a closed-loop control system the system uses feedback to drive system behavior/performance toward a specific objective or set of objectives – and this is not exactly what a TSC would do.

              In my opinion, the flaw in this model for what the TSC does is that it is not incorrect behavior for a TSC to “drive” the transport system to achieve performance that is better than requested.  For example, in a truly closed-loop control system having an objective to provide a latency of – for example – 100 nanoseconds – the system could need to buffer input if necessary to avoid a latency much less than this.

              A TSC that establishes a transport slice having a maximum latency less that 100 nanoseconds would meet this criteria if the actual measured latency was 25 nanoseconds and should not take any corrective actions to “fix” this.  At the same time, a TSC should not take what might be considered extreme steps to achieve a maximum latency (for instance) that is below that it commits to in a transaction.

              On top of this reservation, it is entirely possible (even if neither likely or practical) to have a transport network operate on a strictly CAC based control system, where a request is simply denied if it cannot be met using simple resource commitments based on the transport network uncommitted capacity.  In this case, a TSC provides “flow-through” information about transport slice performance, but takes no direct action in response.

              For these reason, I would prefer to avoid the use of “closed-loop optimization” entirely.  It might be sufficient to state that the TSC “should” maintain transport slices as necessary to ensure that transport slice performance meets (or exceeds) the commitment the TSC makes in response to a transport slice request.  I say “should” because it is entirely possible that an operator prefers to address potential performance degradation using the higher-level system.

--
Eric

From: Wubo (lana) <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, February 26, 2020 4:49 AM
To: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>; Eric Gray <[e-mail]<mailto:[e-mail]>>; Jari Arkko <jari.arkko=[e-mail]<mailto:jari.arkko=[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: Pull-request #9: Reza’s proposed text for Transport Slice Controller (TSC) Northbound Interface (NBI)
Importance: High

Hi Reza and Eric,

Please see my comments inline with [Bo].

发件人: Teas-ns-dt [mailto:[e-mail]] 代表 Rokui, Reza (Nokia - CA/Ottawa)
发送时间: 2020年2月26日 14:26
收件人: Eric Gray <[e-mail]<mailto:[e-mail]>>; Jari Arkko <jari.arkko=[e-mail]<mailto:jari.arkko=[e-mail]>>; [e-mail]<mailto:[e-mail]>
抄送: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>
主题: Re: [Teas-ns-dt] Pull-request #9: Reza’s proposed text for Transport Slice Controller (TSC) Northbound Interface (NBI)

Please see inline.

Reza


From: Eric Gray <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, February 25, 2020 at 6:21 PM
To: Reza Rokui <[e-mail]<mailto:[e-mail]>>, Jari Arkko <jari.arkko=[e-mail]<mailto:jari.arkko=[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: Pull-request #9: Reza’s proposed text for Transport Slice Controller (TSC) Northbound Interface (NBI)

Reza,

              I suspect that we will need to agree to disagree on the issue of optimization and analytics, and hear from others on this topic.

              I could be convinced to make an observation that any TSC implementation that does not take into account some form of service and connection optimization may not be commercially viable – but I see little point in making this observation in a framework document.
[Reza] this is exactly my point. We in most cases talk about the TSC characteristics on automating the creation/deletion/modification of transport slices.
However, as you indicated the concept of assurance of transport slices is as important since  in practice deploying transport slices without assurance is pointless.

              IMO, “analytics” is primarily a marketing “buzz-word” with no clear and common definition – consequently adding it to this document is worse than useless – particularly if we’re including any implicit or explicit assertion that it is “essential.”
[Reza] My suggestion is to use term “Transport Slice Assurance“. This means that TSC shall have functionality to cover Transport Slice Assurance in two areas:

  *   Monitoring  (dropping analytics)
  *   Closed-loop optimization
[Bo] Could you explain the  “Closed-loop optimization “? Does it mean that the higher layer system obtains the monitoring result of transport slices and initiates a modification of the slices?

              But I would like to find out if others disagree.

              On the data-structure, I am afraid you need to be a lot more specific in how “details” differs from “content.”  What exactly are you saying needs to be retained?
[Reza] this statement contradicts whatever Jari asked. In my original draft, I had more details on all these. I am fine to bring back the original text but I need to hear from others as well.
[Bo] I recall that during the conference call, it was agreed that the NBI model definition is the second step. Therefore, the reason why the model structure needs to be added is not clear to me .

As for Reza’s suggested text in the previous email:
The NBI model shall have the following attributes:

  *   Attributes to allow correlation of transport slice to high-level NS request
  *   General attributes on transport slice
  *   Specific attributes such as list of endpoints, SLO, list of connections, policies to allow flexibility on implementation of transport slices and assurance on them.


I think these attributes  are already reflected in the definition draft.

Thanks,
Bo

From: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, February 25, 2020 10:00 AM
To: Eric Gray <[e-mail]<mailto:[e-mail]>>; Jari Arkko <jari.arkko=[e-mail]<mailto:jari.arkko=[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>
Subject: Re: Pull-request #9: Reza’s proposed text for Transport Slice Controller (TSC) Northbound Interface (NBI)
Importance: High

Please see inline.

Reza




From: Eric Gray <[e-mail]<mailto:[e-mail]>>
Date: Monday, February 24, 2020 at 4:46 PM
To: Jari Arkko <jari.arkko=[e-mail]<mailto:jari.arkko=[e-mail]>>, Reza Rokui <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: Pull-request #9: Reza’s proposed text for Transport Slice Controller (TSC) Northbound Interface (NBI)

Agree with Jari, completely.

Also, see additional comments below…

From: Teas-ns-dt <[e-mail]<mailto:[e-mail]>> On Behalf Of Jari Arkko
Sent: Sunday, February 23, 2020 5:04 PM
To: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [Teas-ns-dt] Pull-request #9: Reza’s proposed text for Transport Slice Controller (TSC) Northbound Interface (NBI)

This email concerns Pull-request #9: Reza’s proposed text for
Transport Slice Controller (TSC) Northbound Interface (NBI).  This
review is again a personal review, not holding any hats, just
providing my opinion.

I think this is useful material as well, thank you Reza! I do think
though that many of the details of the way that the NBI  data model
is designed are probably worth placing in the actual NBI document
later. The framework needs to talk about what the NBI is and what
we expect out of it, and some of the general issues, but it does
not need to detail, e.g., data model structure or make detailed
design decisions about specific ways of accomplishing those
goals.
[Reza] Agreed on no details

> As shown in Figure 1, the Transport Slice Controller NBI interfaces
> provides the abstaction of the transport slices to the higher level
> system.  It simplifies the automation, assurance and optimization of
> transport slices by hiding all the complexity of the transport slice
> for realization and monitoring.

I think I'd write this as

    The Transport Slice Controller provides a Northbound Interface (NBI)
    that allows consumers of network slices to request and monitor
    transport slices. The consumers operate on abstract transport slices,
    with the details related to their realisation hidden.
[Reza] OK

> The main characteristics of these
> new interfaces are:
>
> * These interfaces allow a request and response about resources.
>   It should not allow negotiation, as this would be complex and not
>   have a clear benefit

This is too low-level detail for this document. Lets design the NBI in
another document, later. I also don't know yet if the request-response
or negotiation are the right technical choices.  But we don't need to
decide that in this document.
[Reza] OK

> * The provider of these interfaces is the higher layer sytem which
>   needs to create an E2E network slice.  The provider of this
>   interface is the lower layer netowork controllers which provide
>   the realization of the connectivities (i.e. transport slice).

I would like to remove all discussion of the e2e slices and slicing
from our documents. It is distracting, and ultimately leads to a need
to having to detail how 3GPP systems work. It is also not the only
case for slicing, as someone may need slices even when  they are
not constructing an end-to-end  slice. We from the IETF provide
a transport slice, end of story :-)
[Reza] Fine with me

> * These interfaces are needed in industry to achieve true standard
>   based automation of E2E network slices.  It provides technology-
>   agnostic intent-based interfaces to the higher level system (note
>   that as an example, these interfaces are similar to interfaces
>   defined by 3GPP for 5G RAN and 5G Core slices)

Mumble. I'd say too low level detail, plus maybe the language
on automation is not as technical as it should be in this type of
document.
[Reza] Fine to remove

> * These interfaces are independent of type of network functions or
>   services which needs to be connected, i.e. it is independent of
>   any specific repository, software usage, protocol, or platform
>   which realizes the physical or virtual network functions.

This is ok.

> * These interfaces standardizes a way to learn about what resources
>   are available in the network which impact the creation of the
>   transport slices

Mumble. An implementation detail in the controller and/or southbound
issue and/or general network management issue. I'd say not for our
document.
[Reza] Fine to remove


> * These technology independent interfaces simplify the
>   creation/modification/deletion of the transports slices by
>   describing it in a standard way along with all the endpoints that
>   compose a transport slice, their properties, attributes and their
>   SLO requirements

We already said this, in other words.
[Reza] Fine

> * These interfaces provide capabilities for transport slice
>   monitoring and analytics which means that these interface allow
>   enabling/disabling the collection of the transport slices
>   telemetry, assurance and Threshold Crossing Alert (TCA) data and
>   providing them to the higher level system

I don't think we should talk about analytics or other functions that
might be performed on top either the NBI or the controller.

EG > Text relating to “optimization” or “analytics” definitely has no place in this document.
[Reza] Disagree.
This document should talk about optimization and analytics of transport slices. It is essential part of TSC.
TSC’s role is not only automating the creation/modification/deletion of transport slices but also assurance/monitoring/optimization.
Having said that, this document should not talk about how to do these two functions.

> * These interfaces provide capabilities for optimization of the
>   transport slices.  Since the E2E network slices are dynamic in
>   nature, it is important to make sure the transport slice SLOs are
>   valid and in case any SLO violation, the transport slice
>   controller performs the closed-loop action and inform the higher
>   layer system for the violation and closed-loop action.  These
>   interfaces allow this fucntionality.

I think this is again outside scope.

EG > Text relating to “optimization” or “analytics” definitely has no place in this document.
[Reza] Disagree. Please see my response to previous comment.
We can re-word this paragraph if needed.


> * These interfaces allows binding and association between
>   "Transport slices" to "Other Slices"

I don't understand. What slices are you talking about?

EG > My interpretation of what is meant here makes me feel bleak.  The function of a “higher-level” entity should be to figure out how the request Transport Slice fits into a larger context (whether end-to-end, or otherwise); this is definitely not the role reasonable people should expect the TSC to fill.
[Reza] Fine with remove

> * These interfaces complements various IETF services, tunnels, path
>   models by providing an abstract layer on top of these models

Ok, good!

> # Transport Slice Controller NBI high level data model
>
> Figure 3 shows the high level data model of TSC NBI interfaces.  The
> aim is to illustate the main building block of the data model.  For
> complete NBI YANG model see rrrrr (author's note: This is the new
> draft on NBI YANG):
>
>    |----------------------------------------------------------------|
>    | module: transport-slice                                        |
>    | +--rw transport-slice                                          |
>    |   +--rw transport-slice-info                                   |
>    |    +--rw ts-id                                                 |
>    |      +--rw ts-name                                             |
>    |      +--...                                                    |
>    |    +--rw e2e-network-slice-info [ns-id]                        |
>    |       +--rw list of e2e network slice id                       |
>    |       +--rw customer (aka tenant)                              |
>    |       +--rw service type (e.g. CCTV, infotainment etc)         |
>    |       +--...                                                   |
>    |    +--rw transport-slice-group* [tsg-id]                       |
>    |       +--rw tsg-id                                             |
>    |          +--...                                                |
>    |       +--rw endpoint* [endpoint-id]                            |
>    |          +--rw endpoint-id                                     |
>    |          +--...                                                |
>    |       +--rw connection-link* [link-id]                         |
>    |          +--rw link-id                                         |
>    |          +--rw endpoint-A                                      |
>    |          +--rw endpoint-B                                      |
>    |          +--...                                                |
>    |       +--rw transport-slice-policy* [policy-id]                |
>    |          +--rw policy-id                                       |
>    |          +--rw policy-type (e.g. slo-policy, selection-policy, |
>    |                                  assurance-policy)             |
>    |          +--...                                                |
>    |----------------------------------------------------------------|
>
>       Figure 3: Transport Slice Controller NBI high-level data model

Way too detailed for this document. Lets save this for draft-ietf-teas-dt-nbi-00  :-)
[Reza] I am ok with removing the details on data structure. I agree it is not needed here.
However, the content should be present here. They should not be removed

> Refering to Figure 3, the proposed TSC NBI data model should include
> the following building blocks:
>
> * transport-slice-info: It contains information  related to transport
> slice such as transport slice name, transport slice ID etc.
>
> * e2e-network-slice-info: A list of all E2E network slices mapped to
>   a transport slice.  Note that transport slice to E2E network slice
>   is a one-to-many mapping, i.e. one transport slice can be used
>   inside more that one e2e network slice
>
> * transport-slice-group: A transport slice is a set of transport-
>   slice-groups where each of them contains a set of distint
>   connections.  Each transport-slice-group contains:
>
>       * list of endpoints: A transport slice comprises a set of
>         connection among various endpoints.  These attributes
>         specify the endpoint in a generic fashion. The possible
>         attributes of the endpoint could be IP address, node name,
>         domain ID and termination points etc. The details will be
>         provided in TSC NBI YANG draft.
>
>       * list of connection-links: These are the list of connections
>         between endpoints.
>
>       * list of transport-slice-policies: The request from TSC NBI
>         to create the transport slices will have optional and mandatory
>         policies, which specify the desired "transport slice SLO" along with
>         information on monitorig and mapping functions. This draft
>         proposes three types of transport slice policies to be supported.
>         The details of these policies shall be provided in TSC NBI YANG draft:
>
>              * transport-slice-slo-policy: This is a mandatory policy, which
>                represents in a generic and technology-agnostics way the required
>                "transport slice SLO" needed to realize a transport slice.
>                It is defined per transport-slice-group and contains the
>                bounded latency, bandwidth, reliability, security etc.
>
>              * transport-slice-selection-policy: This is an optional policy.
>                In some deployment, the higher level system might want to influence
>                the transport slice controller (TSC) on how to realize a transport
>                slice by providing some information regarding the type of technologies
>                and tunnels.
>
>              * transport-slice-assurance-policy: This is an optional policy.
>                The higher level system might want to influence the transport slice
>                controller for transport slice assurance on how to perform
>                monitoring, analytics and optimization.  This policy will be used
>                and contains, the type of assurance needed, time interval,
>                how often inform the higher level system etc.

Some of this is ok, but should be described at an abstract level, some
of it is way beyond the scope of this document.  We're not defining
the NBI here.

In conclusion, I'd suggest to keep the following text:

    The Transport Slice Controller provides a Northbound Interface (NBI)
    that allows consumers of network slices to request and monitor
    transport slices. The consumers operate on abstract transport slices,
    with the details related to their realisation hidden.

    The NBI is independent of type of network functions or
    services which needs to be connected, i.e. it is independent of
    any specific repository, software usage, protocol, or platform
    which realizes the physical or virtual network functions.

   The NBI complements various IETF services, tunnels, path
   models by providing an abstract layer on top of these models.

   The NBI is based on protocol mechanisms and information
   passed over those mechanisms to convey the desired
   transport slices and their status. The information is expected
   to be represented as a well-defined data model, and should
   include at least endpoint and connectivity information,
   SLO specification, and status information.
[Reza] Fine with above text.
In addition, I am suggesting to add the following.
The NBI model shall have the following attributes:

  *   Attributes to allow correlation of transport slice to high-level NS request
  *   General attributes on transport slice
  *   Specific attributes such as list of endpoints, SLO, list of connections, policies to allow flexibility on implementation of transport slices and assurance on them.