Re: [Teas-ns-dt] Framework to ACTN Applicability

[Kiran Makhijani <[e-mail]>]

Hi Eric,
Can we say for TS framework, MDSC and MPI have visible role?

              If we ignore the "customer" in the transport slice part of the figure, then we could argue that the CNC and MDSC both together are analogous to the TSC - using you argument below.  With that as an example mapping, the "CMI" interface goes away, and ACTN does not have an analogy for our NBI.
^^^^^
I like this simplification that we don't want to say CNC+MSDC = TSC.
Given that 'an orchestrator' performs many slice-specific functions, in addition to identifying a transport network slice, which is then sent down to TSC over NBI. So actually only 3 mappings are possible.

  1.  ORCH --->NBI--->CNC. Then CNC is TSC. How CNC does things down below we don't care.
  2.  ORCH -->CMI -->MDSC, then there is no NBI. So, this is not in our scope.
  3.  ORCH -->NBI-->TSC-->CMI-->CNC, indirect but can be done. This has business case where customers already have CNC, TSC will perform the functions related to SLO guarantees.

Maybe we could explain the text in this way?
On the question of SBI, I am OK  with its details being out of scope.
-Kiran

From: Eric Gray <[e-mail]>
Sent: Monday, June 29, 2020 8:45 AM
To: Kiran Makhijani <[e-mail]>om>; [e-mail]
Subject: RE: Framework to ACTN Applicability

Kiran,

              Your points below sum up a portion of the discussion that has been ongoing for some time, and is the reason why we need to point out that this is just one possible mapping of transport slice control functions and interfaces to ACTN control functions and interfaces.

              Looking at what the ACTN components are defined as, it is critically important to recall that ACTN is all about how to create virtual networks to satisfy some arbitrary customer's requirements using an undelay TE network.

              In that sense, because of the level of abstraction, one could assert that (in some cases) the mapping between ACTN components and transport slice components are defined one way, while (in other cases) they are defined entirely differently.  Essentially, these abstract definitions  are entirely too fuzzy to rigidly define a mapping between the components in one set to the components in the other.

              In wanting to find that component that is closest (in general) to the TSC (which is the main component in our work), I looked in particular at the part of the definition of MDSC that claims that its "key role" is to "detach the network/service requirements from the underlying technology.

              If we ignore the "customer" in the transport slice part of the figure, then we could argue that the CNC and MDSC both together are analogous to the TSC - using you argument below.  With that as an example mapping, the "CMI" interface goes away, and ACTN does not have an analogy for our NBI.

              Without that particular construction, the analogy ignores a big part of the work we eventually expect to complete (i.e. - NBI).

              In that sense, while mapping the CNC (and MDSC combined) to the TSC is a possible interpretation, it is not a useful example.

              In another interpretation, the CNC role (responsible for communicating a customer's VN requirements) means that it is the logical "box" that a customer talks to (using some undefined - and likely both local and non-standard - interface).  Presumably the CNC communicates these VN requirements to the MDSC using the CMI and - since we can view the MDSC as analogous to the TSC (see its "key role" - either above or in ACTN) - that makes the CMI analogous to our NBI.

              This interpretation is more useful, in that sense.  There is an analog to both the TSC and the NBI.

              The remainder of the analogy is essentially academic.  In our work, the SBI and Network Controller (NC) are out of scope and included to provide some idea of the logic involved between the NBI, the TSC and "whatever" is below it.  Since - in our work - the SBI and NC are entirely assumed, it is not useful to struggle with the precise details of their construction and whether or not they are an exact mapping (SBI ==> MPI, PNC ==> NC) to ACTN.

              It is certainly possible to assume the simple case - as a possibility, at least - that they do map in this way.

--
Eric


From: Teas-ns-dt <[e-mail]<mailto:[e-mail]>> On Behalf Of Kiran Makhijani
Sent: Monday, June 29, 2020 10:21 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [Teas-ns-dt] Framework to ACTN Applicability

Hi Eric and All,
Bringing my question to the mailing list. From the discussion, I started to think that an ACTN framework can be used in more than one ways. For example, we may have

  1.  TSC mapped to CNC, from NBI perspective. which is my most preferred positioning (what follows below - we don't concern with).
  2.  TSC maps to MDSC. Then CNC will be the component that takes a transport slice's NBI model.
  3.  NC mapped to PNC in some cases. But it may map to MDSC (may be? - I don't know).

For each scenario reference points CMI and MPI will move accordingly. Am I right?

Maybe it is more useful to describe in this way. Then we can also include how other orchestrators such as NFVI/MANO would use this framework (or reference points on how they plug in).

Regards
Kiran