Subject: [Teas-ns-dt] Comments to the ACTN reference in the framework document during today's call

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Thu, 5 Mar 2020 17:24:49 +0000

Because of the same reason as before, I couldn't verbally comment on this, so in case you didn't echoed my comment I share by mail.

My question here is: should not the mapping to ACTN be considered as a potential solution and in consequence go to a solutions draft? I think framework document should be rather generic, and the explicit mapping to ACTN (at least, as it is now) can create confusion.

I mention this because another possible view of looking to that could be to consider CNC as the higher level system, not necessarily at the same level as the TSC, sicne TSC and Network controller could be the same piece, thus mapping to the MDSC.  So, in my view, such mapping is not straightforward.

Best regards

Luis

__________________________________
Luis M. Contreras

Technology and Planning
Transport, IP and Interconnection Networks
Telefónica I+D / Global CTIO unit / Telefónica

Distrito Telefónica, Edificio Sur 3, Planta 3
28050 Madrid
España / Spain

Skype (Lync): +34 91 312 9084
Mobile: +34 680 947 650
[email-masked]<mailto:[email-masked]>

________________________________

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: Dhruv Dhody <[email-masked]>
Date: Fri, 6 Mar 2020 12:28:54 +0530

Hi Luis,

On Thu, Mar 5, 2020 at 10:54 PM LUIS MIGUEL CONTRERAS MURILLO
<[email-masked]> wrote:
>
> Because of the same reason as before, I couldn’t verbally comment on this, so in case you didn’t echoed my comment I share by mail.
>
>
>

I think it is critical that some context setting is required with
existing published work in TEAS WG. This is different from the
"mapping and realization" piece of the transport network slicing
(which could be out of scope as you have indicated).

Not including this section, creates its own confusion with the very
first questions being - how does this work with existing TEAS
standards.

> I mention this because another possible view of looking to that could be to consider CNC as the higher level system, not necessarily at the same level as the TSC, sicne TSC and Network controller c…

Another way to look at it is in terms of interfaces. TSC speaks TSC
SBI in southbound; CNC speaks CMI in its southbound. So the current
mapping fits nicely! And that is why TSC NBI is needed (which did not
exist in ACTN).

To me a higher-level-system (beyond transport networks) acting as CNC
is a case of a collapsed controllers, which is quite usual as these
functions can be combined and split as per RFC 8453.

Thanks!
Dhruv

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

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Fri, 6 Mar 2020 15:20:03 +0000

Hi Dhruv,

I see your point. I don't have any problem showing relationship with existing work (that's fine), but maybe it could be convenient to refer to it as "exemplary" or "potential" or whatever other way of indicating that it is only a possible case. Maybe moving it to an annex can have the same effect.

Regarding the different angles to look at the mapping, I understand your approach. The only risk here is to derive from it that the TSC has the same functionality of the CNC, which could not be the case.

In summary, I'm not against your rationale, I would like simply to keep the things general to leave room for analyzing further how they could actually fit to existing outcomes from TEAS and/or other WGs. Maybe we are anticipating something that could not be fully correct afterwards.

Best regards

Luis

-----Mensaje original-----
De: Dhruv Dhody <[email-masked]>
Enviado el: viernes, 6 de marzo de 2020 7:59
Para: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
CC: [email-masked]
Asunto: Re: [Teas-ns-dt] Comments to the ACTN reference in the framework document during today's call

Hi Luis,

> My question here is: should not the mapping to ACTN be considered as a potential solution and in consequence go to a solutions draft? I think framework document should be rather generic, and the ex…

I think it is critical that some context setting is required with existing published work in TEAS WG. This is different from the "mapping and realization" piece of the transport network slicing (which could be out of scope as you have indicated).

Not including this section, creates its own confusion with the very first questions being - how does this work with existing TEAS standards.

> I mention this because another possible view of looking to that could be to consider CNC as the higher level system, not necessarily at the same level as the TSC, sicne TSC and Network controller c…

Another way to look at it is in terms of interfaces. TSC speaks TSC SBI in southbound; CNC speaks CMI in its southbound. So the current mapping fits nicely! And that is why TSC NBI is needed (which did not exist in ACTN).

To me a higher-level-system (beyond transport networks) acting as CNC is a case of a collapsed controllers, which is quite usual as these functions can be combined and split as per RFC 8453.

Thanks!
Dhruv

> 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
> --
> Teas-ns-dt mailing list
> [email-masked]

---

From: Eric Gray <[email-masked]>
Date: Mon, 9 Mar 2020 12:31:21 +0000

If you have a chance to read the latest version of draft-ejj-teas-ns-framework-00.txt, you should see that this is substantially less confusing now - because the bulk of the ACTN terminology/concepts alignment text has been moved to a separate section, while there is mention of using ACTN to show how "mapping" to underlying network technologies may be done, in addition to suggested approaches from enhanced VPN.

-----Original Message-----
From: Teas-ns-dt <[email-masked]> On Behalf Of Dhruv Dhody
Sent: Friday, March 6, 2020 1:59 AM
To: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Cc: [email-masked]
Subject: Re: [Teas-ns-dt] Comments to the ACTN reference in the framework document during today's call

Hi Luis,

Thanks!
Dhruv

---

From: Eric Gray <[email-masked]>
Date: Mon, 9 Mar 2020 12:41:11 +0000

Dhruv,

	As discussed briefly in the last meeting, there is some potential for confusion by including you ACTN "mapping" text in the "mapping" section.

	Your text was really about showing the alignment or logical conversion between the terminology and concepts we are using in the teas-ns-dt work and that used in ACTN.

	I agree that this is critical information from a framework (or background) perspective so I moved it into its own section.

	The intention of the mapping section in Jari's original framework outline was (or has now become) intended to describe the "mapping" that the controller needs to do from requests it receives from a higher-level system or controller, to the underlying network, and vice-versa.

	In this document, some discussion of this "mapping" - complete with examples - needs to be included to clarify the role of the transport slice controller, along with the need for a northbound interface.

--
Eric

-----Original Message-----
From: Teas-ns-dt <[email-masked]> On Behalf Of Dhruv Dhody
Sent: Friday, March 6, 2020 1:59 AM
To: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Cc: [email-masked]
Subject: Re: [Teas-ns-dt] Comments to the ACTN reference in the framework document during today's call

Hi Luis,

Thanks!
Dhruv

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 9 Mar 2020 18:16:25 +0530

Hi Eric,

I am happy with the restructuring, it works!

Thanks!
Dhruv

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Mon, 9 Mar 2020 13:28:36 +0000

Hi Eric, Dhruv,

I have been checking existing version in https://github.com/teas-wg/teas-ns-dt/blob/master/framework/draft-ejj-teas-ns-framework-00.txt

As reader, I think it would be more convenient to put current section 3 on applicability of ACTN later in the document than at the very beginning. Reason for that is because probably it makes sense to introduce before framework and considerations, and then show a potential example case such as the applicability of ACTN to that.

In the way it is structured now it seems such as if we were defining how to extend ACTN to support transport slices, not the other way around, that is, how ACTN can be a potential realization of the Transport Slice Controller.

I acknowledge this is my particular view, so I will not fight if the rest don't share this view.

Best regards

Luis

-----Mensaje original-----
De: Dhruv Dhody <[email-masked]>
Enviado el: lunes, 9 de marzo de 2020 13:46
Para: Eric Gray <[email-masked]>
CC: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; [email-masked]
Asunto: Re: [Teas-ns-dt] Comments to the ACTN reference in the framework document during today's call

Hi Eric,

Thanks!
Dhruv

On Mon, Mar 9, 2020 at 6:11 PM Eric Gray <[email-masked]> wrote:
> To: LUIS MIGUEL CONTRERAS MURILLO
> <[email-masked]>
> Cc: [email-masked]
> > 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
> > --
> > Teas-ns-dt mailing list
> > [email-masked]

---

From: Eric Gray <[email-masked]>
Date: Mon, 9 Mar 2020 13:34:28 +0000

If nobody else objects, I would have no particular issue with interchanging sections 3 and 4.  Of course it is not quite that simple - largely because the reference to ACTN in the mapping section (under Framework/Mapping) would now have to be a forward reference, rather than a backward reference (as it is now).

But what do others think?

--
Eric

-----Original Message-----
From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]> 
Sent: Monday, March 9, 2020 9:29 AM
To: Dhruv Dhody <[email-masked]>; Eric Gray <[email-masked]>
Cc: [email-masked]
Subject: RE: [Teas-ns-dt] Comments to the ACTN reference in the framework document during today's call
Importance: High

Hi Eric, Dhruv,

I have been checking existing version in https://protect2.fireeye.com/v1/url?k=d8ac9fa1-84789708-d8acdf3a-865b3b1e120b-8c783861eebd5dd4&q=1&e=aa249f68-66ef-4756-bb60-5f751b27adba&u=https%3A%2F%2Fgithub.com%2Fteas-wg%2Fteas-ns-dt%2Fblob%2Fmaster%2Fframework%2Fdraft-ejj-teas-ns-framework-00.txt

Best regards

Luis

-----Mensaje original-----
De: Dhruv Dhody <[email-masked]>
Enviado el: lunes, 9 de marzo de 2020 13:46
Para: Eric Gray <[email-masked]>
CC: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; [email-masked]
Asunto: Re: [Teas-ns-dt] Comments to the ACTN reference in the framework document during today's call

Hi Eric,

Thanks!
Dhruv

---

From: Eric Gray <[email-masked]>
Date: Mon, 9 Mar 2020 13:36:11 +0000

By the way, this is really not a question for Dhruv - who probably is not particularly concerned about where it is in the draft - but for Jari, John And myself (as Editors).

--
Eric

-----Original Message-----
From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]> 
Sent: Monday, March 9, 2020 9:29 AM
To: Dhruv Dhody <[email-masked]>; Eric Gray <[email-masked]>
Cc: [email-masked]
Subject: RE: [Teas-ns-dt] Comments to the ACTN reference in the framework document during today's call
Importance: High

Hi Eric, Dhruv,

Best regards

Luis

-----Mensaje original-----
De: Dhruv Dhody <[email-masked]>
Enviado el: lunes, 9 de marzo de 2020 13:46
Para: Eric Gray <[email-masked]>
CC: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; [email-masked]
Asunto: Re: [Teas-ns-dt] Comments to the ACTN reference in the framework document during today's call

Hi Eric,

Thanks!
Dhruv

---

From: Jari Arkko <[email-masked]>
Date: Mon, 9 Mar 2020 13:46:39 +0000

I have no objection to the 3-4 swap. In fact it might be a good idea.

Jari

---

From: John E Drake <[email-masked]>
Date: Mon, 9 Mar 2020 19:49:04 +0000

Eric,

I think your proposal makes sense.  

Yours Irrespectively,

John

Juniper Business Use Only

> From: Teas-ns-dt <[email-masked]> On Behalf Of Eric Gray
> Sent: Monday, March 9, 2020 9:34 AM
> <[email-masked]>; Dhruv Dhody
> <[email-masked]>
> Cc: [email-masked]
> If nobody else objects, I would have no particular issue with interchanging
> sections 3 and 4.  Of course it is not quite that simple - largely because the
> reference to ACTN in the mapping section (under Framework/Mapping) would
> now have to be a forward reference, rather than a backward reference (as it is
> now).
> 
> From: LUIS MIGUEL CONTRERAS MURILLO
> I have been checking existing version in
> https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=d8ac9fa1-
> 84789708-d8acdf3a-865b3b1e120b-8c783861eebd5dd4&q=1&e=aa249f68-
> 66ef-4756-bb60-5f751b27adba&u=https*3A*2F*2Fgithub.com*2Fteas-
> wg*2Fteas-ns-dt*2Fblob*2Fmaster*2Fframework*2Fdraft-ejj-teas-ns-
> framework-00.txt__;JSUlJSUlJSUl!!NEt6yMaO-gk!VdbGHo6G5NiB7Kw88ld-
> XTn_o5BXmplfBQoWkWt9dPlqZEoKn_JRawjrmqBWu0I$
> 
> As reader, I think it would be more convenient to put current section 3 on
> applicability of ACTN later in the document than at the very beginning. Reason
> for that is because probably it makes sense to introduce before framework and
> considerations, and then show a potential example case such as the applicability
> of ACTN to that.
> 
> In the way it is structured now it seems such as if we were defining how to
> extend ACTN to support transport slices, not the other way around, that is, how
> ACTN can be a potential realization of the Transport Slice Controller.
> 
> CC: LUIS MIGUEL CONTRERAS MURILLO
> <[email-masked]>; [email-masked]
> >         As discussed briefly in the last meeting, there is some potential for
> confusion by including you ACTN "mapping" text in the "mapping" section.
> >
> >         Your text was really about showing the alignment or logical conversion
> between the terminology and concepts we are using in the teas-ns-dt work and
> that used in ACTN.
> >
> >         I agree that this is critical information from a framework (or background)
> perspective so I moved it into its own section.
> >
> >         The intention of the mapping section in Jari's original framework outline
> was (or has now become) intended to describe the "mapping" that the controller
> needs to do from requests it receives from a higher-level system or controller,
> to the underlying network, and vice-versa.
> >
> >         In this document, some discussion of this "mapping" - complete with
> examples - needs to be included to clarify the role of the transport slice
> controller, along with the need for a northbound interface.
> >
> > --
> > Eric
> >
> > > Because of the same reason as before, I couldn’t verbally comment on this,
> so in case you didn’t echoed my comment I share by mail.
> > >
> > >
> > >
> > > My question here is: should not the mapping to ACTN be considered as a
> potential solution and in consequence go to a solutions draft? I think framework
> document should be rather generic, and the explicit mapping to ACTN (at least,
> as it is now) can create confusion.
> > >
> >
> > I think it is critical that some context setting is required with existing published
> work in TEAS WG. This is different from the "mapping and realization" piece of
> the transport network slicing (which could be out of scope as you have
> indicated).
> >
> > Not including this section, creates its own confusion with the very first
> questions being - how does this work with existing TEAS standards.
> >
> > >
> > >
> > > I mention this because another possible view of looking to that could be to
> consider CNC as the higher level system, not necessarily at the same level as the
> TSC, sicne TSC and Network controller could be the same piece, thus mapping to
> the MDSC.  So, in my view, such mapping is not straightforward.
> > >
> >
> > Another way to look at it is in terms of interfaces. TSC speaks TSC SBI in
> southbound; CNC speaks CMI in its southbound. So the current mapping fits
> nicely! And that is why TSC NBI is needed (which did not exist in ACTN).
> >
> > To me a higher-level-system (beyond transport networks) acting as CNC is a
> case of a collapsed controllers, which is quite usual as these functions can be
> combined and split as per RFC 8453.
> >
> > Thanks!
> > Dhruv
> >
> > >
> > >
> > > Best regards
> > >
> > >
> > >
> > > Luis
> > >
> > >
> > >
> > > 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.
> > >
> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/te
> > > as-ns-dt__;!!NEt6yMaO-gk!VdbGHo6G5NiB7Kw88ld-
> XTn_o5BXmplfBQoWkWt9dPl
> > > qZEoKn_JRawjrcC7zMTg$
> >
> > --
> > Teas-ns-dt mailing list
> > [email-masked]
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > -ns-dt__;!!NEt6yMaO-gk!VdbGHo6G5NiB7Kw88ld-
> XTn_o5BXmplfBQoWkWt9dPlqZEo
> > Kn_JRawjrcC7zMTg$
> 
> 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
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas-ns-
> dt__;!!NEt6yMaO-gk!VdbGHo6G5NiB7Kw88ld-
> XTn_o5BXmplfBQoWkWt9dPlqZEoKn_JRawjrcC7zMTg$