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

[Eric Gray <[e-mail]>]

Kiran,

We show them as visible in the figure now, but the "visibility" of the MPI is of dubious value in out goal to describe the role of the TSC and NBI.

As an academic exercise, my understanding is that what we refer to as "SBI" would likely include an MPI at least at some low level.  This is strictly an academic exercise, however as we would be arguing details about out-of-scope logic.

In the original figure (initially proposed by Dhruv), the CNC was shown as analogous to TSC.  This was problematic given the text that was also proposed initially to describe the figure; that text seems to describe the CNC as analogous to the "higher level system" (which collects and communicates VN requirements) and the MDSC as analogous to TSC (because it is responsible for multi-domain coordination, virtualization/abstraction, customer mapping/translation and virtual service coordination to realize the VN requirement).

Moreover, if we were to wholly subscribe to the idea that CNC is analogous to TSC, then the rest of ACTN would be inapplicable - i.e. we could simply say that the CNC logical concept from ACTN is approximately analogous to TSC and the applicability of ACTN ends right there.

I will be sending out my proposal for replacing the content of this section in a few minutes.

Note that I may be sending it from my personal account as I am having (what has lately become perennial) problems with mailing stuff to myself...

--
Eric

From: Kiran Makhijani <[e-mail]>
Sent: Monday, June 29, 2020 2:36 PM
To: Eric Gray <[e-mail]>om>; [e-mail]
Subject: RE: Framework to ACTN Applicability
Importance: High

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]<mailto:[e-mail]>>
Sent: Monday, June 29, 2020 8:45 AM
To: Kiran Makhijani <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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