Subject: [Actn] ACTN architecture and interfaces

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 29 Sep 2014 18:52:42 +0100

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

---

From: Leeyoung <[email-masked]>
Date: Mon, 29 Sep 2014 18:07:34 +0000

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

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Mon, 29 Sep 2014 21:01:58 +0000

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,

                .--------------
               -------------   |
              | Application |--
               -------------
                     |
                     | I/F A                 --------
                     v                      (        )
                --------------             -          -

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

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: Leeyoung <[email-masked]>
Date: Mon, 29 Sep 2014 22:57:57 +0000

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

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,

                .--------------
               -------------   |
              | Application |--
               -------------
                     |
                     | I/F A                 --------
                     v                      (        )
                --------------             -          -

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

---

From: Leeyoung <[email-masked]>
Date: Mon, 29 Sep 2014 23:07:43 +0000

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,

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. 

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

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,

                .--------------
               -------------   |
              | Application |--
               -------------
                     |
                     | I/F A                 --------
                     v                      (        )
                --------------             -          -

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

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

---

From: Zhenghaomian <[email-masked]>
Date: Tue, 30 Sep 2014 03:34:27 +0000

Hi, Luis and Young,

This is very interesting topic, for a recursive architecture. I think for each VNC, there is some level of abstraction (can be either simpler or more complicated) and I would like to abstract it to three types of interfaces based on Young's previous email:

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

This is very similar to a customer-provider relationship. Any other more complicated recursive architecture can be considered as a combination of the structures above. CNC may also be considered as a special kind of VNC, which plays a customer role and can also be recursive. 

Another question is, the interface option b), may be an internal communication, and we need to be careful whether this need to be standardized, or maybe it can be left as provider-specific. 

Besides, for Fig. 5, it is already clear on the vertical direction for me. Actually in horizontal direction, we still have 1-to-N case, i.e., one VNC for multiple PNC (or VNC), which was discussed in a separated email. Hopefully both of these are included in our scope. 

Please correct me if anything misunderstood, thank you. 

Best wishes,
Haomian

-----邮件原件-----
发件人: Leeyoung [mailto:[email-masked]] 
发送时间: 2014年9月30日 6:58
收件人: LUIS MIGUEL CONTRERAS MURILLO; [email-masked]; [email-masked]
抄送: 'Alia Atlas'
主题: Re: [Actn] ACTN architecture and interfaces

Hi Luis,

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

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,

                .--------------
               -------------   |
              | Application |--
               -------------
                     |
                     | I/F A                 --------
                     v                      (        )
                --------------             -          -

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