Subject: Re: [Actn] ACTN architecture and interfaces

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 1 Oct 2014 13:21:53 +0000

Hi Young, Luis,

Interesting topic. I concur with Young when saying that the interface between a VNCs in a recursive architecture is of "type" B. 
Regarding the two different options below:

> a) VNC (Provider X) --- i/f B.2 ----- VNC (Provider Y) ---- i/f C ---- PNC
> (Provider Y)
> b) VNC (Provider X) --- i/f B.1 ----- VNC (Provider X) ---- i/f C ---- PNC
> (Provider X)

I see the recursiveness of VNCs within the same provider ( b) as an extremely uncommon corner cases, which, if needed, might be addressed as a particular case of a). 
Is there a reason for a provider to have a recursiveness of VNCs? If the goal is to enhance scalability I would say that it is a matter increasing the number of PNC under the control of the same VNC but I think case a) is enough.

BR
Daniele

> -----Original Message-----
> From: ACTN [mailto:[email-masked]] On Behalf Of Leeyoung
> Sent: martedì 30 settembre 2014 01:08
> To: Leeyoung; LUIS MIGUEL CONTRERAS MURILLO; [email-masked];
> [email-masked]
> Cc: 'Alia Atlas'
> Subject: Re: [Actn] ACTN architecture and interfaces
> 
> Hi Luis,
> 
> I meant
> 
> b) VNC (Provider X) --- i/f B.1 ----- VNC (Provider X) ---- i/f C ---- PNC
> (Provider X)
> 
> Sorry.
> Young
> 
> -----Original Message-----
> From: ACTN [mailto:[email-masked]] On Behalf Of Leeyoung
> Sent: Monday, September 29, 2014 5:58 PM
> To: LUIS MIGUEL CONTRERAS MURILLO; [email-masked]; [email-masked]
> Cc: 'Alia Atlas'
> Subject: Re: [Actn] ACTN architecture and interfaces
> 
> Hi Luis,
> 
> This case is a bit advanced topic (a variation from the base architecture) but I
> think it is a good topic to grapple sooner than later.
> 
> Your scenarios make me think we might need to have two dimensions in the
> interface definition for Interface B. Perhaps B.1 and B.2 where B.1 an internal
> interface and B.2 an external interface. An internal interface means the two
> end entities belong to the same operator while an external interface means
> the two end entities belong to two different administrative operators. For
> VNC-PNC, we may not need to distinguish internal or external as the
> assumption made was it is only internal (of course, this assumption can be
> relaxed in a more general case, but for now let us stay with this assumption
> for this thread).
> 
> With this in mind, I think the base architecture in Figure 5 in Section 6.1.1 is
> more or less CNC  --- i/f B.1 ----- VNC ----i/f C ----- PNCs.
> 
> Note that VNC is assumed to provide multi-domain coordination function
> (interfacing multiple PNCs).
> 
> The case you brought up is more or less:
> 
> a) VNC (Provider X) --- i/f B.2 ----- VNC (Provider Y) ---- i/f C ---- PNC
> (Provider Y)
> b) VNC (Provider X) --- i/f B.1 ----- VNC (Provider X) ---- i/f C ---- VNC
> (Provider X)
> 
> Note: CNC-VNC is omitted as this can be either B.1 or B.2 depending on the
> relationship between CNC and VNC.
> 
> I would say the relationship between VNCs are more or less i/f B (rather than
> i/f C) as they are more or less similar to CNC-VNC. That is the reason for the
> above mapping a) and b).
> 
> This is an interesting discussion. I might have missed your points and I am
> sure that there are different perspectives.
> Let's see how other folks look at this problem.
> 
> Best regards,
> Young
> 
> 
> 
> -----Original Message-----
> From: LUIS MIGUEL CONTRERAS MURILLO
> [mailto:[email-masked]]
> Sent: Monday, September 29, 2014 4:02 PM
> To: Leeyoung; [email-masked]; [email-masked]
> Cc: 'Alia Atlas'
> Subject: RE: [Actn] ACTN architecture and interfaces
> 
> Hi Young
> 
> One question raised to me when thinking about recursiveness in this
> architecture. What would be the schema in case where a VNC communicates
> with another VNC? This could be an scenario where a virtual network
> provider builds its offered transport network capabilities total or partially on
> top of another virtual network provider.
> 
> There are some alternatives:
> 
> a) CNC -- (i/f B) -- VNC -- { -- (i/f B) -- VNC -- (i/f C) -- PNC}
> b) CNC -- (i/f B) -- VNC -- { -- (i/f C) -- VNC -- (i/f C) -- PNC}
> c) both of them
> 
> Regards
> 
> Luis
> 
> 
> -----Mensaje original-----
> De: ACTN [mailto:[email-masked]] En nombre de Leeyoung Enviado
> el: lunes, 29 de septiembre de 2014 20:08
> Para: [email-masked]; [email-masked]
> CC: 'Alia Atlas'
> Asunto: Re: [Actn] ACTN architecture and interfaces
> 
> Hi Adrian,
> 
> Thanks for your bringing up this architecture discussion to the list. I feel it
> might be useful to bring up here Figure 5:
> 
>                 .--------------
>                -------------   |
>               | Application |--
>                -------------
>                      |
>                      | I/F A                 --------
>                      v                      (        )
>                 --------------             -          -
>                | Customer     |           (  Customer  )
>                |  Network     |--------->(    Network   )
>                |   Controller |           (            )
>                 --------------             -          -
>                      |                      (        )
>                      | I/F B                 --------
>                      v                        ^    ^
>                 --------------                :    :
>                | Virtual      |               :     .
>                |  Network     |               :      .
>                |   Controller |            --------   . I/F E
>                 --------------            (        )   .
>                      |                   -          -   .
>                      | I/F C            (  Physical  )   .
>                      v                 (    Network   )   .
>                   ---------------       (            )     --------
>                  |               |-----> -          -     (        )
>                 --------------   |        (        )     -         -
>                | Physical     |--          --------     (  Physical  )
>                |  Network     |----------------------->(    Network   )
>                |   Controller |         I/F D           (            )
>                 --------------                           -         -
>                                                           (        )
>                                                            --------
> 
> 
>                          Figure 5. ACTN Interfaces
> 
> As you pointed out, the quoted charter and Section 6.1.1 of the framework
> draft are consistent in that both of them limit the scope of ACTN work to I/F
> B and I/F C (Figure 5) that correspond to the CNC-VNC and VNC-PNC
> interface, respectively. Other interfaces are out of scope. They are shown for
> an illustration purpose to give the overarching context of ACTN.
> 
> Best regards,
> Young
> 
> -----Original Message-----
> From: ACTN [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Monday, September 29, 2014 12:53 PM
> To: [email-masked]
> Cc: 'Alia Atlas'
> Subject: [Actn] ACTN architecture and interfaces
> 
> Hi,
> 
> Thanks for the latest revision of
> http://www.ietf.org/id/draft-ceccarelli-actn-framework-03.txt
> I find the new Figure 5 particularly helpful in understanding the potential
> scope of the ACTN work. And this is important because at this stage if the
> process we are trying to work out exactly what an ACTN working group might
> work on if it was created.
> 
> Looking at the v1.3 draft charter text at
> https://sites.google.com/site/actnbof/home/charter-proposal I see...
> > This architecture shows three
> > control components: the Customer Network Controller (CNC) responsible
> > for servicing requests from applications (such as OSS/NMS), the
> > Virtual Network Controller (VNC) responsible for realizing customer
> > networks out of physical network resources, and the Physical Network
> > Controller (PNC) responsible for control and provisioning in physical
> > networks. The architecture shows the need for interfaces between these
> components.
> 
> I just want to check what this means. I read it as saying that interfaces B and
> C as shown on Figure 5 are in scope for an ACTN working group, but all other
> interfaces shown on the figure are not in scope. I believe this is consistent
> with Section 6.1.1 of the draft.
> 
> Can y'all confirm that this is your understanding and what you want to work
> on and exclude.
> 
> Thanks,
> Adrian
> 
> _______________________________________________
> ACTN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/actn
> 
> _______________________________________________
> ACTN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/actn
> 
> ________________________________
> 
> 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
> _______________________________________________
> ACTN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/actn
> _______________________________________________
> ACTN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/actn

---

From: Leeyoung <[email-masked]>
Date: Wed, 1 Oct 2014 17:07:39 +0000

Hi Daniele,

I agree with you that VNC-VNC for the same provider is a corner case where Case a) can cover well with trust/security constraint aspect being relaxed. But I wanted Luis to comment on that; he may be aware of the case like that as Telefonica is dealing with global networks where I can see a potential for that case.

Thanks,
Young

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]] 
Sent: Wednesday, October 01, 2014 8:22 AM
To: Leeyoung; LUIS MIGUEL CONTRERAS MURILLO; [email-masked]; [email-masked]
Cc: 'Alia Atlas'
Subject: RE: [Actn] ACTN architecture and interfaces

Hi Young, Luis,

Interesting topic. I concur with Young when saying that the interface between a VNCs in a recursive architecture is of "type" B. 
Regarding the two different options below:

> a) VNC (Provider X) --- i/f B.2 ----- VNC (Provider Y) ---- i/f C ---- 
> PNC (Provider Y)
> b) VNC (Provider X) --- i/f B.1 ----- VNC (Provider X) ---- i/f C ---- 
> PNC (Provider X)

BR
Daniele

> b) VNC (Provider X) --- i/f B.1 ----- VNC (Provider X) ---- i/f C ---- 
> PNC (Provider X)
> 
> Sorry.
> Young
> 
> This case is a bit advanced topic (a variation from the base 
> architecture) but I think it is a good topic to grapple sooner than later.
> 
> Your scenarios make me think we might need to have two dimensions in 
> the interface definition for Interface B. Perhaps B.1 and B.2 where 
> B.1 an internal interface and B.2 an external interface. An internal 
> interface means the two end entities belong to the same operator while 
> an external interface means the two end entities belong to two 
> different administrative operators. For VNC-PNC, we may not need to 
> distinguish internal or external as the assumption made was it is only 
> internal (of course, this assumption can be relaxed in a more general 
> case, but for now let us stay with this assumption for this thread).
> 
> With this in mind, I think the base architecture in Figure 5 in 
> Section 6.1.1 is more or less CNC  --- i/f B.1 ----- VNC ----i/f C ----- PNCs.
> 
> a) VNC (Provider X) --- i/f B.2 ----- VNC (Provider Y) ---- i/f C ---- 
> PNC (Provider Y)
> b) VNC (Provider X) --- i/f B.1 ----- VNC (Provider X) ---- i/f C ---- 
> VNC (Provider X)
> 
> Note: CNC-VNC is omitted as this can be either B.1 or B.2 depending on 
> the relationship between CNC and VNC.
> 
> I would say the relationship between VNCs are more or less i/f B 
> (rather than i/f C) as they are more or less similar to CNC-VNC. That 
> is the reason for the above mapping a) and b).
> 
> This is an interesting discussion. I might have missed your points and 
> I am sure that there are different perspectives.
> architecture. What would be the schema in case where a VNC 
> communicates with another VNC? This could be an scenario where a 
> virtual network provider builds its offered transport network 
> capabilities total or partially on top of another virtual network provider.
> 
> Thanks for your bringing up this architecture discussion to the list. 
> I feel it might be useful to bring up here Figure 5:
> 
>                 .--------------
>                -------------   |
>               | Application |--
>                -------------
>                      |
>                      | I/F A                 --------
>                      v                      (        )
>                 --------------             -          -
> As you pointed out, the quoted charter and Section 6.1.1 of the 
> framework draft are consistent in that both of them limit the scope of 
> ACTN work to I/F B and I/F C (Figure 5) that correspond to the CNC-VNC 
> and VNC-PNC interface, respectively. Other interfaces are out of 
> scope. They are shown for an illustration purpose to give the overarching context of ACTN.
> 
> Best regards,
> Young
> 
> I find the new Figure 5 particularly helpful in understanding the 
> potential scope of the ACTN work. And this is important because at 
> this stage if the process we are trying to work out exactly what an 
> ACTN working group might work on if it was created.
> 
> > control components: the Customer Network Controller (CNC) 
> > responsible for servicing requests from applications (such as 
> > OSS/NMS), the Virtual Network Controller (VNC) responsible for 
> > realizing customer networks out of physical network resources, and 
> > the Physical Network Controller (PNC) responsible for control and 
> > provisioning in physical networks. The architecture shows the need 
> > for interfaces between these
> components.
> 
> I just want to check what this means. I read it as saying that 
> interfaces B and C as shown on Figure 5 are in scope for an ACTN 
> working group, but all other interfaces shown on the figure are not in 
> scope. I believe this is consistent with Section 6.1.1 of the draft.
> 
> Can y'all confirm that this is your understanding and what you want to 
> work on and exclude.
> 
> Thanks,
> Adrian
> 
> 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.
> 
> 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 MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Wed, 1 Oct 2014 17:07:22 +0000

Hi Daniele,

I tend to agree with you. Seems to be a corner case, at least I don't realize now a clear scenario for that.

I have an additional comment regarding these ideas. If the recursive architecture is based on type B interfaces between VNC provider X and VNC Provider Y, in contrast to maintaining an interface of type C with a Physical provider called for instance Z, this means that Provider X is aware that Provider Y is not a Physical provider (at least totally, i.e., not all the transport capabilities are owned by Provider Y).

I wonder if this could have further implications from several perspectives: SLAs, information exposure, etc.

Just sharing my thoughts,

Regards

Luis

-----Mensaje original-----
De: Daniele Ceccarelli [mailto:[email-masked]]
Enviado el: miércoles, 01 de octubre de 2014 15:22
Para: Leeyoung; LUIS MIGUEL CONTRERAS MURILLO; [email-masked]; [email-masked]
CC: 'Alia Atlas'
Asunto: RE: [Actn] ACTN architecture and interfaces

Hi Young, Luis,

BR
Daniele

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 MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Wed, 1 Oct 2014 17:11:30 +0000

Hi Young, good point the reference to global networks. However at the end these global networks are structured as separated domains, so we could assume them as actually separated networks. Anyway let me think a little bit more on that, just to realize if there could be a real use case sustaining it.

Regards

Luis

-----Mensaje original-----
De: Leeyoung [mailto:[email-masked]]
Enviado el: miércoles, 01 de octubre de 2014 19:08
Para: Daniele Ceccarelli; LUIS MIGUEL CONTRERAS MURILLO; [email-masked]; [email-masked]
CC: 'Alia Atlas'
Asunto: RE: [Actn] ACTN architecture and interfaces

Hi Daniele,

Thanks,
Young

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Wednesday, October 01, 2014 8:22 AM
To: Leeyoung; LUIS MIGUEL CONTRERAS MURILLO; [email-masked]; [email-masked]
Cc: 'Alia Atlas'
Subject: RE: [Actn] ACTN architecture and interfaces

Hi Young, Luis,

BR
Daniele