Re: [Teas-ns-dt] Figure in the ACTN Applicability section

[Dhruv Dhody <[e-mail]>]

Hi Eric, DT,

Lets continue the discussion from the call -

- I agree with the fact that everything above TSC (and TSC-NBI) can be
a big box and we don't have to worry about it in this I-D.
- Everything below TSC (and TSC-SBI) needs a little more details as
this is something that belongs in the IETF. The TSC-SBI is a TS
realization interface and could have different granularity based on
the network controller it is interfacing with. But we need to clarify
that it is NOT the customer service model (L3SM etc).
- We can further discuss if describing things in terms of RFC 8309
models is useful, I saw some usefulness at least to drive the
discussion.
- I agree with Eric, that a figure is useful. Perhaps we could think
about removing the arrows towards ACTN boxes, if that helps!

Thanks!
Dhruv

On Thu, May 14, 2020 at 8:28 PM Eric Gray
<eric.gray=[e-mail]> wrote:
>
> Folks,
>
>
>
> Obviously, we need to re-assess what to include in the figure.
>
>
>
> In an intermediate figure, I had tried having the MDSC as “floating” between the TSC and the PNC, because (as is clear in these discussions) exactly what the mapping between TSC and specific ACTN entities is the main ambiguity issue in the current section.
>
>
>
> But there is a bigger issue that is also clear in these discussions: some of the areas for minor disagreement in the pictures is in those parts of the figure that are in the “we don’t exactly care” region.
>
>
>
> It is not material (in the Framework draft, at least – but probably in all of the work in scope for the DT) exactly how we define “customer,” (hierarchy of) “orchestration,” and other entities above the point where <_some_ _entity_> issues transport slices requests via the TSC NBI.
>
>
>
> Any of these things may be the “user” of the TSC NBI, and prolonged and detailed discussion about how that happens, or who is who in any process for which the access to the NBI is used, is pretty much irrelevant and a waste of time.
>
>
>
> Similarly, discussion of what goes on “under the hood” of the TSC itself is likewise not tremendously interesting.
>
>
>
> We had agreed that the TSC portion of the figure is useful to the extent that it clarifies logical relationships between the TSC and the logical entities that MAY exist between the TSC and the underlay network it uses to realize transport slices, as well as the logical entities that MAY exist between a customer (for some definition of “customer”), an arbitrary “hierarchy” of 0 or more layers of “orchestration,” and the TSC NBI.
>
>
>
> We also need to talk about at least an outline of a mapping to existing work on ACTN and the work we are doing in the NS-DT.
>
>
>
> I am personally comfortable with doing that entirely without a figure, but experience tells me that many folks are not able to get as much out of any explanation that does not include a figure or two.
>
>
>
> At this point, I would prefer to revisit the figure with the floating relationship between TSC and ACTN – and follow that up with text that describes essentially what I have included above.
>
>
>
> That figure was as follows:
>
>
>
>        +------------------------------------+
>
>        |             Customer               |  |
>
>        +------------------------------------+        ACTN
>
>                          A                     |  Terminology
>
>                          |                        and Concepts
>
>                          V                     |
>
>        +------------------------------------+
>
>        |      A highter level system        |  |   +-----+
>
>        |(e.g e2e network slice orchestrator)| ===> | CNC |
>
>        +------------------------------------+  |   +-----+
>
>                          A                            A
>
>                          | TSC NBI             |      |
>
>                          V                            |
>
>        +------------------------------------+  |      | CMI
>
>       |      Transport Slice Controller    |         V
>
>        +------------------------------------+  |   +------+
>
>                          A                         | MDSC |
>
>                          | TSC SBI             |   +------+
>
>                          | TSC SBI                    A
>
>                          |                     |      | MPI
>
>                          V                            V
>
>        +------------------------------------+  |   +-----+
>
>        |        Network Controller(s)       | ===> | PNC |
>
>        +------------------------------------+  |   +-----+
>
>
>
>                 Terminology/Concepts           |
>
>                Used in this Document
>
>                                                |
>
>
>
> --
>
> Eric
>
>
>
> From: Xufeng Liu <[e-mail]>
> Sent: Thursday, May 14, 2020 9:29 AM
> To: Luis M. Contreras <[e-mail]>
> Cc: Eric Gray <[e-mail]>; [e-mail]
> Subject: Re: [Teas-ns-dt] Figure in the ACTN Applicability section
>
>
>
> Luis's diagram makes more sense to me. Some additional thoughts:
>
>
>
> 1) Transport Slice Controller (TSC) can be hierarchical, so we can have TSC-H and TSC-L, to match MDSC-H and MDSC-L.
>
> 2) The -02 version does not clearly define "A higher level system", which is needed.
>
> 3) It is needed to clearly describe which of these components are slice-aware and which are not.
>
>
>
> Thanks,
>
> - Xufeng
>
>
>
> On Tue, May 12, 2020 at 12:03 PM Luis M. Contreras <[e-mail]> wrote:
>
> (My apologies for the mail before, with the Confidential Notes by default. Please, ignore it. Repeating mail here).
>
>
>
> Hi Eric, all,
>
>
>
> Thanks for addressing this point.
>
>
>
> I have some few comments and suggestions.
>
>
>
> 1/ Regarding the figure, I think that as it is now mix things a bit. In my personal subjective view I think it provides a view of how to fit TSC into ACTN rather in the other way around. My suggestion would be to depict the comparison as in the figure below (ignore the service model naming by now for this point). I think it becomes more clear, but again this is subjective, of course.
>
>
>
> 2/ Regarding the service model naming. I have revisited RFC8309 and I think that the proper mapping to service models in the case of TSC would be the one proposed in the figure below on the left-hand side (please, check Figure 3 in RFC8309).
>
>
>
> Here is the figure I propose.
>
>
>
> Service Model in                                              ACTN
>
>  Transport Slice        Transport Slice Framework           Terminology
>
> Framework [RFC8309]                                         and Concepts
>
> -------------          -------------------------           ------------
>
>                  +------------------------------------+
>
>                  |             Customer               |  |
>
>                  +------------------------------------+
>
>    Customer                        A                     |
>
>    Service                         |
>
>    Model                           V                     |
>
>                  +------------------------------------+
>
>                  |      A highter level system        |  |   +-----+
>
>                  |(e.g e2e network slice orchestrator)| ===> | CNC |
>
>                  +------------------------------------+  |   +-----+
>
>    Service                         A                            A
>
>    Delivery                        | TSC NBI             |      | CMI
>
>    Model                           V                            V (LxSM)
>
>                  +------------------------------------+  |   +-------+
>
>                  |      Transport Slice Controller    | ===> | MDSC-H|
>
>                  +------------------------------------+  |   +-------+
>
>                                    A                            A
>
>                                    |                     |      |
>
>                                    |                            V
>
>    Network                         |                     |   +-------+
>
>    Configuration                   | TSC SBI                 |MDSC-L |
>
>    Model                           |                     |   +-------+
>
>                                   |                            A
>
>                                    |                     |      | MPI
>
>                                    V                            V (LxNM)
>
>                  +------------------------------------+  |   +-----+
>
>                  |        Network Controller(s)       | ===> | PNC |
>
>                  +------------------------------------+  |   +-----+
>
>
>
>
>
> The text you propose depends totally on the final figure and the consideration of the service models that apply, so I would prefer to discuss first about the figure and once it is closed to discuss the text, to ensure consistency.
>
>
>
> Thanks
>
>
>
> Luis
>
>
>
> El mar., 12 may. 2020 a las 16:03, Eric Gray (<eric.gray=[e-mail]>) escribió:
>
> John and I had a discussion with Dhruv about some ambiguity in the relationship between some of the entities in the ACTN architecture and the related concepts in our NS-DT work in the Framework draft.
>
>
>
> The upshot is that there is a bit of a slushy relationship between some of the terms that we (the NS design team) have defined (see the definitions draft) and loosely corresponding concepts defined in ACTN.  In particular, there are currently issues with the positioning of the TSC as directly analogous to MDSC, impacting interfaces between these logical components as well.
>
>
>
> After a few iterations in discussion, Dhruv, John and I agreed to propose a replacement figure and text as shown immediately below.
>
>
>
>        +------------------------------------+
>
>        |             Customer               |  |
>
>        +------------------------------------+
>
>                          A                     |     ACTN
>
>                          |                        Terminology
>
>                          V                     |  and Concepts
>
>        +------------------------------------+
>
>        |      A highter level system        |  |   +-----+
>
>        |(e.g e2e network slice orchestrator)| ===> | CNC |
>
>        +------------------------------------+  |   +-----+
>
>                          A                            A
>
>                          | TSC NBI             |      | CMI
>
>                          V                            V (LxSM)
>
>        +------------------------------------+  |   +-------+
>
>        |      Transport Slice Controller    | ===> | MDSC-H|
>
>        +------------------------------------+  |   +-------+
>
>                          A                            A
>
>                          | TSC SBI (LxNM)      |      |
>
>                          V                            V
>
>        +------------------------------------+  |   +-------+
>
>        |        Network Controller(s)       | ===> |MDSC-L |
>
>        +------------------------------------+  |   +-------+
>
>                                                       A
>
>                 Terminology/Concepts           |      | MPI
>
>                Used in this Document                  V
>
>                                                |   +-----+
>
>                                                    | PNC |
>
>                                                |   +-----+
>
>
>
>
>
> We would also add further clarifying text along the lines of:
>
>
>
> The TS-NBI would be at the same level as the customer service models (LxSM), except that it uses a technology agnostic service model where as LxSM does not.
>
>
>
> We add hierarchy to the MDSC concept in this figure so that the mapping with LxNM might be easier to see.  But the TSC could also directly interact with multiple domain controllers in which case we have a single MDSC.
>
>
>
> If nobody objects, or has additional input they would like to provide, we would like to go ahead and make this change to the Framework draft.
>
>
>
> If necessary, we can discuss this at the meeting on Thursday (14 May).
>
>
>
> --
>
> Eric
>
> --
> Teas-ns-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas-ns-dt
>
>
>
>
> --
>
> ___________________________________________
>
> Luis M. Contreras
>
> [e-mail]
>
> [e-mail]
>
> Global CTIO unit / Telefonica
>
> --
> Teas-ns-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas-ns-dt
>
> --
> Teas-ns-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas-ns-dt