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

From: Eric Gray <[email-masked]>
Date: Tue, 12 May 2020 14:02:41 +0000

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

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 12 May 2020 15:57:49 +0000

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

De: Teas-ns-dt <[email-masked]> En nombre de Eric Gray
Enviado el: martes, 12 de mayo de 2020 16:03
Para: [email-masked]
Asunto: [Teas-ns-dt] Figure in the ACTN Applicability section
Importancia: Alta

       |             Customer               |  |

                         A                     |     ACTN

                         |                        Terminology

                         V                     |  and Concepts

                         A                            A

                         | TSC NBI             |      | CMI

                         V                            V (LxSM)

                         A                            A

                         | TSC SBI (LxNM)      |      |

                         V                            V

                                                      A

               Used in this Document                  V

                                               |   +-----+

                                                   | PNC |

                                               |   +-----+

--

Eric

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: "Luis M. Contreras" <[email-masked]>
Date: Tue, 12 May 2020 18:03:06 +0200

(My apologies for the mail before, with the Confidential Notes by default.
Please, ignore it. Repeating mail here).

Hi Eric, all,

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).

Service Model in                                              ACTN

                 |             Customer               |  |

   Customer                        A                     |

   Service                         |

   Model                           V                     |

   Service                         A                            A

   Model                           V                            V (LxSM)

                                   A                            A

                                   |                     |      |

                                   |                            V

   Network                         |                     |   +-------+

   Model                           |                     |   +-------+

                                  |                            A

                                   |                     |      | MPI

                                   V                            V (LxNM)

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=
[email-masked]>) 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.
>
>
>
> 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.
>
>
>
> Teas-ns-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas-ns-dt
>

-- 
___________________________________________
Luis M. Contreras
[email-masked]
[email-masked]
Global CTIO unit / Telefonica

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 14 May 2020 09:29:11 -0400

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 <[email-masked]>
wrote:

> 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).
>
>
>
>> 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

---

From: Eric Gray <[email-masked]>
Date: Thu, 14 May 2020 14:58:22 +0000

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 <[email-masked]>
Sent: Thursday, May 14, 2020 9:29 AM
To: Luis M. Contreras <[email-masked]>
Cc: Eric Gray <[email-masked]>; [email-masked]
Subject: Re: [Teas-ns-dt] Figure in the ACTN Applicability section

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 <[email-masked]<mailto:[email-masked]>> wrote:
(My apologies for the mail before, with the Confidential Notes by default. Please, ignore it. Repeating mail here).

Hi Eric, all,

Service Model in                                              ACTN

Thanks

Luis

El mar., 12 may. 2020 a las 16:03, Eric Gray (<eric.gray=[email-masked]<mailto:[email-masked]>>) escribió:

       |             Customer               |  |

                         A                     |     ACTN

                         |                        Terminology

                         V                     |  and Concepts

                         A                            A

                         | TSC NBI             |      | CMI

                         V                            V (LxSM)

                         A                            A

                         | TSC SBI (LxNM)      |      |

                         V                            V

                                                      A

               Used in this Document                  V

                                               |   +-----+

                                                   | PNC |

                                               |   +-----+

--

Eric
--
Teas-ns-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas-ns-dt

--
___________________________________________
Luis M. Contreras
[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>
Global CTIO unit / Telefonica
--
Teas-ns-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas-ns-dt

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 14 May 2020 23:08:00 +0530

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=[email-masked]> wrote:
> On Tue, May 12, 2020 at 12:03 PM Luis M. Contreras <[email-masked]> wrote:
>
> El mar., 12 may. 2020 a las 16:03, Eric Gray (<eric.gray=[email-masked]>) escribió:
>

---

From: John E Drake <[email-masked]>
Date: Thu, 14 May 2020 17:46:22 +0000

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 <[email-masked]> On Behalf Of Dhruv Dhody
> Sent: Thursday, May 14, 2020 1:38 PM
> To: Eric Gray <eric.gray=[email-masked]>
> Cc: haomianzheng <[email-masked]>; Luis M. Contreras
> <[email-masked]>; Xufeng Liu <[email-masked]>; Kiran
> Makhijani <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate)
> <[email-masked]>; [email-masked]
> [External Email. Be cautious of content]
> 
> 
> Hi Eric, DT,
> 
> - 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
> 
> > 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.
> >
> >
> >
> > 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.
> >
> >
> >
> > 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.
> >
> >
> >
> 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).
> >
> >
> >
> > 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=[email-masked]>) escribió:
> >
> > 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.
> >
> >
> >
> > 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.
> >
> >
> >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > -ns-dt__;!!NEt6yMaO-
> gk!VAg0Vz27PX9nHj1eNBVGWt0LwRfVXuZn7V_O62U0sL-2uRR
> > uv_UFfyXBGARF8hg$
> >
> >
> >
> >
> > --
> >
> > 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
> > [email-masked]
> > 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
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas-ns-
> dt__;!!NEt6yMaO-gk!VAg0Vz27PX9nHj1eNBVGWt0LwRfVXuZn7V_O62U0sL-
> 2uRRuv_UFfyXBGARF8hg$

---

From: Eric Gray <[email-masked]>
Date: Thu, 14 May 2020 18:41:03 +0000

John and Dhruv,

              Actually 0 or more "SBIs" _MAY_ exist.

              We should not discuss how the TSC produces its magic, except loosely and in logical terms.

              It is fairly easy to envision a transport slice service that is provided by a single physical box, or even a single virtual function within a box that provides multiple such functions, possibly among others.

              In the event that this is the case, and we certainly have no reason to exclude this possibility, there would quite likely be no SBI at all (what exactly would be the point?).

              Conversely, a TSC implementation might be conceived (and implemented) that uses entirely proprietary mechanisms to provision the underlying network infrastructure.

              Again, we cannot rule this possibility out, and again there would be no SBI (or at least none specified by the IETF).

              That is not to say that either of these implementation examples would not offer visibility to appropriate model information.  Such could be done in any case where the appropriate standard model can be mapped to what the TSC actually does.  This is why a logical model may be defined, but does not guarantee that services are exactly realized as described by that model.

              As a result, we do not – at least in the framework – need to delve very deeply into how the TSC _MAY_ use any form of SBI as, doing so at this point would likely restrict implementation options unnecessarily.

              Also see embedded replies below…

--

Eric

-----Original Message-----
From: John E Drake <jdrake=[email-masked]>
Sent: Thursday, May 14, 2020 1:46 PM
To: Dhruv Dhody <[email-masked]>; Eric Gray <[email-masked]>
Cc: haomianzheng <[email-masked]>; Luis M. Contreras <[email-masked]>; Xufeng Liu <[email-masked]>; Kiran Makhijani <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; [email-masked]
Subject: RE: [Teas-ns-dt] Figure in the ACTN Applicability section
Importance: High

Dhruv,

Yours Irrespectively,

John

--- [SNIP - Juniper disclaimer removed] ---

> From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of Dhruv

> Dhody

> To: Eric Gray <eric.gray=[email-masked]<mailto:eric.gray=[email-masked]>>

> Cc: haomianzheng <[email-masked]<mailto:[email-masked]>>; Luis M. Contreras

> <[email-masked]<mailto:[email-masked]>>; Xufeng Liu <[email-masked]<mailto:[email-masked]>>;

> Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Belotti, Sergio (Nokia -

> IT/Vimercate) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

> --- [SNIP - Ericsson disclaimer removed] ---

> this is something that belongs in the IETF.

It is not in our charter to “provide details” for everything that “belongs to the IETF.”

We can – and should – provide examples, where possible, but not as an exhaustive list.

Unless doing so is necessary to highlight specific issues that we need to resolve, in this project.

Are you arguing that is the case?

> The TSC-SBI is a TS

> the network controller it is interfacing with.

This will only be the case if we  are unable to define the NBI abstraction, and the TSC, in such a way that they hide the way that the TSC uses any presumed SBI – including the possibility that the TSC does not explicitly use any SBI.

Also, how the TSC realizes any transport slice is explicitly out of scope in this project.

> But we need to clarify  that it is NOT the customer service model (L3SM etc).

We only need to clarify this to the extent that we might describe any service model in any detail.

A network operator _MAY_ certainly use L3SM models to manage their L3 services.  But what we are working on is a higher layer abstraction that – itself – _MAY_ uses L3SM models, L2SM models, other models, or no models at all.

> models is useful, I saw some usefulness at least to drive the discussion.

> about removing the arrows towards ACTN boxes, if that helps!

That is essentially the figure that I suggested (look at it again).

I am hard-pressed to argue objectively about including a figure.  I do not personally like them, because (as Reza intimated) pictures can (and often do) leave a lo open to (possibly incorrect) interpretation.

If anything, I tend to include too few figures.

But I do not think that we are at fault if people base their conclusions entirely on a figure, without carefully reading text that is included to clarify the meaning of the figure.  At least not unless the figure is highly misleading, or the text is not consistent with the figure – as either of these situations will inevitably produce more confusion than clarity.

And, as I said during the meeting, a lot of folks simply _MUST_ have a figure.  The adage they cite is “A picture is worth a thousand words.”  As a rule, as implied above, I am exactly the opposite.  I reply “Give me the thousand words, or you wasted time creating the picture.”

I suspect that others are like me in that the only thing I am naturally inclined to conclude from a picture is whether or not it is esthetically pleasing.

In my experience, if you give a “pictures please” person a purely textual explanation, they will immediately start drawing a figure – which they will then need to confirm with the authors is correct – hence drawing out the intended communication process.  You can easily determine that you are dealing with such a person, because A) they want to draw a figure, and B) they likely will not get it right the first one or two times they try.

It takes all kinds.

If the folks in the design team feel that the mapping of this work to the work done in ACTN is not complicated enough to warrant a figure, I am willing to take it out.

> <eric.gray=[email-masked]<mailto:eric.gray=[email-masked]>> wrote:

> > 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

> > 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.

> > From: Xufeng Liu <[email-masked]<mailto:[email-masked]>>

> > To: Luis M. Contreras <[email-masked]<mailto:[email-masked]>>

> > Cc: Eric Gray <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

> > 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.

> > slice-aware

> and which are not.

> > On Tue, May 12, 2020 at 12:03 PM Luis M. Contreras

> <[email-masked]<mailto:[email-masked]>> wrote:

> > 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).

> > 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.

> (<eric.gray=[email-masked]<mailto:eric.gray=[email-masked]>>) escribió:

> 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

> > (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

> > If nobody objects, or has additional input they would like to

> > provide, we would

> > https://protect2.fireeye.com/v1/url?k=1eaec4cb-400e2455-1eae8450-86e

> > e86bd5107-f483cc5da58c33bd&q=1&e=54580c1a-e1c9-4821-ab55-4d147d30d06

> > a&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org

> > %2Fmailman%2Flistinfo%2Fteas

> > https://protect2.fireeye.com/v1/url?k=7fc5cb69-21652bf7-7fc58bf2-86e

> > e86bd5107-bcf121b69ec9b593&q=1&e=54580c1a-e1c9-4821-ab55-4d147d30d06

> > a&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org

> > %2Fmailman%2Flistinfo%2Fteas

> > https://protect2.fireeye.com/v1/url?k=78f842d7-2658a249-78f8024c-86e

> > e86bd5107-764e815231c9d43f&q=1&e=54580c1a-e1c9-4821-ab55-4d147d30d06

> > a&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org

> > %2Fmailman%2Flistinfo%2Fteas

> https://protect2.fireeye.com/v1/url?k=153b4b4d-4b9babd3-153b0bd6-86ee8

> 6bd5107-4b38ef80511ff65e&q=1&e=54580c1a-e1c9-4821-ab55-4d147d30d06a&u=

> https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmai

> lman%2Flistinfo%2Fteas-ns-

---

From: John E Drake <[email-masked]>
Date: Thu, 14 May 2020 19:46:18 +0000

Eric,

Comment inline.  As an aside, because of my pysics training, I would like to reduce any protocol or definition I-D to a small set of generalized rules, e.g., Maxwell's equations, kdformadescription to

Yours Irrespectively,

John

Juniper Business Use Only
From: Eric Gray <eric.gray=[email-masked]>
Sent: Thursday, May 14, 2020 2:41 PM
To: John E Drake <[email-masked]>; Dhruv Dhody <[email-masked]>
Cc: haomianzheng <[email-masked]>; Luis M. Contreras <[email-masked]>; Xufeng Liu <[email-masked]>; Kiran Makhijani <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; [email-masked]
Subject: RE: [Teas-ns-dt] Figure in the ACTN Applicability section

John and Dhruv,

              As a result, we do not - at least in the framework - need to delve very deeply into how the TSC _MAY_ use any form of SBI as, doing so at this point would likely restrict implementation options unnecessarily.

[JD]  I think we're in pretty good shape, in that we refer to plural SBIs.  Perhaps we should make it explicit that there are a multiplicity of SBIs, as well as you two further points, above, that there may not be an SBI or that it may be proprietary.

              Also see embedded replies below...

--

Eric

-----Original Message-----
From: John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>
Sent: Thursday, May 14, 2020 1:46 PM
To: Dhruv Dhody <[email-masked]<mailto:[email-masked]>>; Eric Gray <[email-masked]<mailto:[email-masked]>>
Cc: haomianzheng <[email-masked]<mailto:[email-masked]>>; Luis M. Contreras <[email-masked]<mailto:[email-masked]>>; Xufeng Liu <[email-masked]<mailto:[email-masked]>>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Teas-ns-dt] Figure in the ACTN Applicability section
Importance: High

Dhruv,

Yours Irrespectively,

John

> this is something that belongs in the IETF.

It is not in our charter to "provide details" for everything that "belongs to the IETF."

We can - and should - provide examples, where possible, but not as an exhaustive list.

> the network controller it is interfacing with.

This will only be the case if we  are unable to define the NBI abstraction, and the TSC, in such a way that they hide the way that the TSC uses any presumed SBI - including the possibility that the TSC does not explicitly use any SBI.

A network operator _MAY_ certainly use L3SM models to manage their L3 services.  But what we are working on is a higher layer abstraction that - itself - _MAY_ uses L3SM models, L2SM models, other models, or no models at all.

But I do not think that we are at fault if people base their conclusions entirely on a figure, without carefully reading text that is included to clarify the meaning of the figure.  At least not unless the figure is highly misleading, or the text is not consistent with the figure - as either of these situations will inevitably produce more confusion than clarity.

And, as I said during the meeting, a lot of folks simply _MUST_ have a figure.  The adage they cite is "A picture is worth a thousand words."  As a rule, as implied above, I am exactly the opposite.  I reply "Give me the thousand words, or you wasted time creating the picture."

In my experience, if you give a "pictures please" person a purely textual explanation, they will immediately start drawing a figure - which they will then need to confirm with the authors is correct - hence drawing out the intended communication process.  You can easily determine that you are dealing with such a person, because A) they want to draw a figure, and B) they likely will not get it right the first one or two times they try.

It takes all kinds.

> > In an intermediate figure, I had tried having the MDSC as "floating"

> figure that are in the "we don't exactly care" region.

> > It is not material (in the Framework draft, at least - but probably

> work in scope for the DT) exactly how we define "customer," (hierarchy

> of) "orchestration," and other entities above the point where <_some_

> > Any of these things may be the "user" of the TSC NBI, and prolonged

> > Similarly, discussion of what goes on "under the hood" of the TSC

> MAY exist between a customer (for some definition of "customer"), an

> arbitrary "hierarchy" of 0 or more layers of "orchestration," and the TSC NBI.

> between TSC and ACTN - and follow that up with text that describes

> > https://protect2.fireeye.com/v1/url?k=1eaec4cb-400e2455-1eae8450-86e<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=1eaec4cb-400e2455-1eae8450-86e__;!!NEt6yMaO-gk!X83L4v3NzeY12vaZiDeoaGAuA2khALtGeMAL_IInNxkDxl-j-5IcObo-NIgXf7U$>

> > https://protect2.fireeye.com/v1/url?k=7fc5cb69-21652bf7-7fc58bf2-86e<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=7fc5cb69-21652bf7-7fc58bf2-86e__;!!NEt6yMaO-gk!X83L4v3NzeY12vaZiDeoaGAuA2khALtGeMAL_IInNxkDxl-j-5IcObo-dv56t-k$>

> > https://protect2.fireeye.com/v1/url?k=78f842d7-2658a249-78f8024c-86e<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=78f842d7-2658a249-78f8024c-86e__;!!NEt6yMaO-gk!X83L4v3NzeY12vaZiDeoaGAuA2khALtGeMAL_IInNxkDxl-j-5IcObo-MNU9ZeA$>

> https://protect2.fireeye.com/v1/url?k=153b4b4d-4b9babd3-153b0bd6-86ee8<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=153b4b4d-4b9babd3-153b0bd6-86ee8__;!!NEt6yMaO-gk!X83L4v3NzeY12vaZiDeoaGAuA2khALtGeMAL_IInNxkDxl-j-5IcObo-CBdGmSA$>

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 18 May 2020 18:46:09 +0530

Hi John, Eric,

I like how John puts it and I agree with that.

Well, I asked to add some more details for the TSC-SBI to clarify its
scope a little more, mainly to make sure that we don't highlight the
customer service models - L3SM, L2SM as examples of TSC SBI (as its
currently done in the definition draft). It was this example that made
me propose the mapping that I did earlier. L3SM is a customer service
model between the customer and service orchestrator and mapping it to
the TSC-SBI would make the new mapping difficult to comprehend
considering RFC 8309 description of customer service models.

I agree with you that we need to define the logical functions of TSC /
network controllers do and the said functions can be implemented in a
single box or multiple (this aligns with RFC 8453 as well).

Thanks!
Dhruv
Dhruv

On Fri, May 15, 2020 at 1:16 AM John E Drake <[email-masked]> wrote:
>
> Eric,
>
>
>
> Comment inline.  As an aside, because of my pysics training, I would like to reduce any protocol or definition I-D to a small set of generalized rules, e.g., Maxwell’s equations, kdformadescription to
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> [JD]  I think we’re in pretty good shape, in that we refer to plural SBIs.  Perhaps we should make it explicit that there are a multiplicity of SBIs, as well as you two further points, above, that there may not be an SBI or that it may be proprietary.
>
>
>
>
>
> > From: Teas-ns-dt <[email-masked]> On Behalf Of Dhruv
>
> > Dhody
>
> > <[email-masked]>; Xufeng Liu <[email-masked]>;
>
> > Kiran Makhijani <[email-masked]>; Belotti, Sergio (Nokia -
>
> > IT/Vimercate) <[email-masked]>; [email-masked]
>
> > <[email-masked]> wrote:
>
> > >
>