Re: [Teas-ns-dt] Transport slice, connections and functions.

[Kiran Makhijani <[e-mail]>]

Thanks Reza, Please see inline for very short explanations. I hope to have more F2F discussions next week.
--
Regards,
Kiran

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[e-mail]>
Date: Tuesday, November 12, 2019 at 11:30 AM
To: Kiran Makhijani <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "Rokui, Reza (Nokia - CA/Ottawa)" <[e-mail]>
Subject: Re: [Teas-ns-dt] Transport slice, connections and functions.

Hi Kiran,

My comments are inline.

Reza



From: Teas-ns-dt <[e-mail]> on behalf of Kiran Makhijani <[e-mail]>
Date: Wednesday, November 13, 2019 at 12:05 AM
To: "[e-mail]" <[e-mail]>
Subject: [Teas-ns-dt] Transport slice, connections and functions.

Hello,
As promised in the call yesterday, I hope we use the following text to better articulate and converge on the discussion on transport connection and functions. We’ll deal separately with what what SFs should be in scope (covered by Luis’s thread).



----- Background -----
We initially started with transport slice as described by Reza:
  - an SLA-guaranteeing inter-connection between 2 networks (e.g. RAN and 5GC).
  - This gives us very simple network resources to work with
      - path latency, bandwidth, resiliency, and reliability.
      - the northbound interface has 2 actors: transport-slice oeprator and transport-slice tenant.
      - allow changes to transport slice by tenants.
      - The realization maybe achieved via ACTN, SR, RSVP etc existing technologies.


[Reza] A good summary of transport slice and its realization using various IETF solutions.


We then extended the discussion include 2 more components: isolation (connectivity SLA?) and service function (also a resource).
   - isolation: is an important end to end characteristic. It allows an operator to offer different type of network services to tenants. Tenants can then use this slice to purpose built network for their applications. It may be achieved via hard of soft resource isolation.

   - service functions: tenants should be able to install their own polices, rules etc in the offered transport slices, therefore, they should be part of transport slices. It is also a means to enable isolation.

[Reza] As discussed in our draft section 3.3 (draft-nsdt-teas-transport-slice-definition-00), both scenarios are possible, i.e. a tenant can just specifies the endpoints and SLA, Or it can OPTIONALLY specify the other service functions.
The result of this has the following important consequence on modeling of northbound interface:


  *   The northbound data model of transport slices shall allow a tenant to request the connectivity between various endpoints with appropriate SLAs. OPTIONALLY it shall also allow various policies, rules, other endpoints etc. along the transport slice implementation.


In both cases, the definition of transport slice does not change but rather the Endpoints and OPTIONAL policies, rules etc.
[kiran] We are saying the same thing. The difference is I prefer to start with a model that has functions both in the middle or as endpoints along with the connections, but general notion as of now in the design team is to  see them only as endpoints and only worry about the connections.


-------Problem --------
My doubt is: If we only consider connectivity as transport slice, we may run into scale challenges when we include service functions. If we don’t include functions then the scope of transport slice is less interesting.

[Reza] As indicated above, we shall support both options. Depends on the use-case one might have scalability problem but that is purely depends on the use-case.
[kiran] On principle it is agreed that both options will be supported. I am only contending that we should discuss and adopt approaches that help to handle scalability problem gracefully.

---- By example------
Now if we only consider slice as a connection then we should guarantee SLAs between SFs. i.e.

    (SF-1)---[ts0]---(SF-2)--[ts1]--(SF-3)
        |
        |----[ts2]--(SF-4)

  Just using above figure as an example, if we only consider connectivity as transport slice, then the tenant will need to create separate transport slices ts0, ts1, ts2 to connect different SFs. This will mean all those transport slices have to be managed/identified seprately. Higher the number of functions and multi-points, scalability challenges will start to show (this looks like micro-managing every link). it is even a bigger challenge for the slice operator, since there's very little abstraction here.

Alternately, we can consider the below figure as one transport slice, managed as a single entity.

    (SF-1)------(SF-2)----(SF-3)
        |
        |------(SF-4)

I assume both the figures as one transport network i.e. same administrative domain. The app-logic or the users of the tenants (users) are not at all invovled. Therefore, they are not end to end slices.

Finally, we may have 2 different administrative domains and there it may need more than one transport slice as below, each meeting same SLA of latency/bw/reliability.
    (ts-1)-----(ts-2)----(ts-3)

[Reza] I am not clear about this picture. Since the transport slices are between various endpoints, what are the endpoints in this case? What is the meaning of dashed lines?
[Kiran] This is to highlight an advanced scenario of stitching, where ts1 and ts3 are say 2 transport slices in separate IGP networks (one may do SR and second may be a DC with SFC) and ts-2 is a transport slice that interconnects them. It may use MPLS or BGP technology. I wanted to get feedback if this should be covered in scope or not?

Maybe chain of SFs is a higher level “non-transport slice”. But I find it less interesting.

Thanks
Kiran