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

[John E Drake <[e-mail]>]

Dhruv,

From my perspective, there are going to be a multiplicity of SBIs, some of which may already exist.    

Yours Irrespectively,

John


Juniper Business Use Only

> -----Original Message-----
> From: Teas-ns-dt <[e-mail]> On Behalf Of Dhruv Dhody
> Sent: Thursday, May 14, 2020 1:38 PM
> To: Eric Gray <eric.gray=[e-mail]>
> Cc: haomianzheng <[e-mail]>; Luis M. Contreras
> <[e-mail]>; Xufeng Liu <[e-mail]>; Kiran
> Makhijani <[e-mail]>; Belotti, Sergio (Nokia - IT/Vimercate)
> <[e-mail]>; [e-mail]
> Subject: Re: [Teas-ns-dt] Figure in the ACTN Applicability section
> 
> [External Email. Be cautious of content]
> 
> 
> 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > -ns-dt__;!!NEt6yMaO-
> gk!VAg0Vz27PX9nHj1eNBVGWt0LwRfVXuZn7V_O62U0sL-2uRR
> > uv_UFfyXBGARF8hg$
> >
> >
> >
> >
> > --
> >
> > ___________________________________________
> >
> > Luis M. Contreras
> >
> > [e-mail]
> >
> > [e-mail]
> >
> > Global CTIO unit / Telefonica
> >
> > --
> > Teas-ns-dt mailing list
> > [e-mail]
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > -ns-dt__;!!NEt6yMaO-
> gk!VAg0Vz27PX9nHj1eNBVGWt0LwRfVXuZn7V_O62U0sL-2uRR
> > uv_UFfyXBGARF8hg$
> >
> > --
> > Teas-ns-dt mailing list
> > [e-mail]
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > -ns-dt__;!!NEt6yMaO-
> gk!VAg0Vz27PX9nHj1eNBVGWt0LwRfVXuZn7V_O62U0sL-2uRR
> > uv_UFfyXBGARF8hg$
> 
> --
> Teas-ns-dt mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas-ns-
> dt__;!!NEt6yMaO-gk!VAg0Vz27PX9nHj1eNBVGWt0LwRfVXuZn7V_O62U0sL-
> 2uRRuv_UFfyXBGARF8hg$