Subject: [Actn] Regarding draft-lopez-actn-vno-multidomains

From: Dhruv Dhody <[email-masked]>
Date: Wed, 18 Jun 2014 11:18:05 +0000

Dear Authors, 

Thanks for the document, few small comments in line for your 
consideration. 

>1. Introduction
>
>   Network operators build and operate their network using multiple
>   domains in different dimensions. Domains may be defined by a
>   collection of links and nodes (each of a different technology),
>   administrative zones under the concern of a particular business
>   entity, or vendor-specific "islands" where specific control
>   mechanisms have to be applied.  Establishing end-to-end connections
>   spanning several of these domains is a perpetual problem for
>   operators, which need to address both interoperability and
>   operational concerns at the control and data planes. The
>   introduction of new services, often requiring connections that
>   traverse multiple domains, needs significant planning, and several
>   manual operations to interface different administrative zones,
>   vendor equipment and technology. This is problem becomes more
>   relevant as the consolidation of virtualization technologies like
>   Network Functions Virtualization (NFV) calls for a more elastic
>   behavior of the transport network, able to support their
>   requirements on dynamic infrastructure reconfiguration [NFV-UC].

Can we elaborate a bit more regarding the impact of NFV? Maybe mention 
especially virtualization of CE and PE devices? Coexistence of 
virtualized and non-virtualized network functions etc?

>   This document provides a use-case that addresses the aforementioned
>   need within a single operator network.
>
>   This use-case is a part of the overarching work, called Abstraction
>   and Control of Transport Networks (ACTN). The goal of ACTN is to
>   facilitate virtual network operation by:
>
>     . The creation of a virtualized environment allowing operators to
>        view the abstraction of the underlying multi-admin, multi-
>        vendor, multi-technology networks and
>
>     . The operation and control/management of these multiple networks
>        as a single virtualized network.
>

Since there will be multiple virtual networks, can we change to 'a single 
virtualized network for a customer' instead? 

>3. Virtual Network Operations for Multi-domain Networks
>
>   Based on the issues discussed in the previous section in regard to
>   the operations for multi-domain networks, we propose the definition
>   of a virtual network operations (VNO) infrastructure that helps
>   operators to establish end-to-end connections spanning multiple
>   domains and its related operation and management issues.
>
>   The VNO Coordinator facilitates virtual network operation, the
>   creation of a virtualized environment allowing operators to view the
>   underlying multi-admin, multi-vendor, multi-technology networks and
>   their operation and management as a single, virtualized network.
>
>   The basic premise of VNO is to create a hierarchy of operations in
>   which to separate virtual network operations from physical network
>   operations. This helps operators build virtual network operations
>   infrastructure on top of physical network operations. Figure 2 shows
>   a hierarchical structure of operations.
>
>                        +----------------------+
>                        |    VNO Coordinator   |
>                        +----------------------+
>                                   |
>                                   | VNO-I
>              .-----------------------------------------.
>              |             |             |             |
>         +----------+  +----------+  +----------+  +----------+
>         |    DCN   |  |    DCN   |  |    DCN   |  |          |
>         | Domain A |  | Domain B |  | Domain C |  | TN Domain|
>         | Control  |  | Control  |  | Control  |  | Control  |
>         |          |  |          |  |          |  |          |
>         +----------+  +----------+  +----------+  +----------+
>               |             |             |             |
>            /----\        /----\        /----\        /----\
>          //      \\    //      \\    //      \\    //      \\
>         |   DC A   |  |   DC B   |  |   DC C   |  | Transport|
>          \\      //    \\      //    \\      //    \\Network/
>            \----/        \----/        \----/        \----/
>
>                      Figure 2. Operations Hierarchy
>
>   Figure 2 shows operations hierarchy based on Figure 1. The two main
>   ideas are:
>
>   1. Domain control/management entities (e.g., DCN Domain Control A, B,
>     C and TN Domain Control) are kept intact to continue its domain
>     operations with its technology choice and policy, etc. As
>     discussed before domain control/management entities can be a form
>     of various types (e.g., SDN-controller, NMS/EMS, Control Plane, or
>     a combination of these entities, etc.) that is responsible for
>     domain-specific network operations.
>
>   2. The VNO Coordinator establishes a standard-based API (which is
>     termed as the Virtual Network Operations Interface (VNO-I) in
>     Figure 2) with each of the domain control/management entities. The
>     VNO coordination takes place via the VNO-I's.

Can this be aligned to the framework document and clarify that VNO 
Coordinator is VNC while DCN and TN control are PNC?  VNO-I is VNC-PNC 
Interface (VPI)?

Also I was wondering if there exist another entity customer similar to 
the framework document? 

>
>3.1. Responsibilities of Domain Control/Management Entities
>
>     . Creation of domain-level abstraction of network topology
>
>        It is the responsibility of domain control/management entity to
>        create an abstraction of its network topology. The level of
>        abstraction varies from one domain to another, subject to local
>        domain policy. All EPs and gateway nodes to other domains need
>        to be represented at a minimum. The level of internal nodes and
>        links may be abstracted according to its domain policy.

Do you think it is possible that domain-level control provides raw 
topology and VNO coordinator is responsible for global abstraction?

Regards,
Dhruv

---------------------------------------------------------------
Dhruv Dhody 
System Architect, 
Huawei Technologies India Pvt. Ltd.,
Banagalore
Mobile: +91-9845062422
This e-mail and its attachments contain confidential information from 
HUAWEI, which is intended only for the person or entity whose address is 
listed above. Any use of the information contained herein in any way 
(including, but not limited to, total or partial disclosure, 
reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please 
notify the sender by phone or email immediately and delete it!

---

From: "Diego R. Lopez" <[email-masked]>
Date: Fri, 20 Jun 2014 04:12:48 +0000

Hi Dhruv,

Thanks for your comments. We'll try to address them in the document as soon as we can. A few replies inlined below...

> virtualized and non-virtualized network functions etc?

I'd prefer not to go for specifically mentioning concrete cases unless you see a special aspect to be remarked (if you do, please let's talk about them). OTOH, you completely right: the coexistence or virtualized and non-virtualized functions is a key aspect, and ACTN should definitely be of help for making it easier.

> virtualized network for a customer' instead?

Shall que use "per tenant", following the common virtualization jargon?

> Coordinator is VNC while DCN and TN control are PNC?  VNO-I is VNC-PNC

This alignment you request makes a lot of sense to me. In fact, wherever there are one-to-one mappings we should use the framework document terminology

> Also I was wondering if there exist another entity customer similar to

I under the impression the customer entity is implicit here, and therefore not mentioned...

> topology and VNO coordinator is responsible for global abstraction?

That's an option, that implies full trust between every domain control entity and the VNO, but other degrees of trust can exist, where a given domain control could not want to share the full detail of its underlying topology to a VNO.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Leeyoung <[email-masked]>
Date: Fri, 20 Jun 2014 04:31:05 +0000

Hi Dhruv,

I think Diego pretty much handled all your comments. One comment I have is concerning your comment on 

>> The operation and control/management of these multiple networks
>> Since there will be multiple virtual networks, can we change to 'a single virtualized network for a customer' instead?

I think the use-case discussed in 'draft-lopez-actn-vno-multidomains' deals with having many different domains under its control and addresses the need for a global operational view on all these domains. In such context, a single virtualized network is for the operator and there is no customer involved here per se. Each domain would provide some abstraction to the VNO-coordinator in which to create a global network abstraction.

Let me know if this makes sense. 
Thanks,

Young 

-----Original Message-----
From: ACTN [mailto:[email-masked]] On Behalf Of Diego R. Lopez
Sent: Thursday, June 19, 2014 11:13 PM
To: Dhruv Dhody
Cc: [email-masked]; [email-masked]
Subject: Re: [Actn] Regarding draft-lopez-actn-vno-multidomains

Hi Dhruv,

> Since there will be multiple virtual networks, can we change to 'a 
> single virtualized network for a customer' instead?

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
_______________________________________________
ACTN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/actn

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 20 Jun 2014 05:24:08 +0000

Hi Diego and Young, 

Thanks for the reply, some comments inline to both the mails...

> From: Leeyoung
> Sent: 20 June 2014 10:01
> To: Diego R. Lopez; Dhruv Dhody
> Subject: RE: [Actn] Regarding draft-lopez-actn-vno-multidomains
> 
> Hi Dhruv,
> 
> >> The operation and control/management of these multiple networks as a
> >> single virtualized network.
> I think the use-case discussed in 'draft-lopez-actn-vno-multidomains' deals
> with having many different domains under its control and addresses the need
> for a global operational view on all these domains. In such context, a single
> virtualized network is for the operator and there is no customer involved
> here per se. Each domain would provide some abstraction to the VNO-
> coordinator in which to create a global network abstraction.
> 
[DD] It does! But I was wondering if it helps to mention a reference to another use-case document (which mentions VN per tenant/customer) or just a sentence clarifying this? 

> Thanks for your comments. We'll try to address them in the document as soon
> as we can. A few replies inlined below...
> 
> I'd prefer not to go for specifically mentioning concrete cases unless you
> see a special aspect to be remarked (if you do, please let's talk about them).
> OTOH, you completely right: the coexistence or virtualized and non-
> virtualized functions is a key aspect, and ACTN should definitely be of help
> for making it easier.
> 
[DD] To me it adds another dimension to technology, administrative zones, vendor-islands etc. I leave the text changes to your better judgment. 
> Shall que use "per tenant", following the common virtualization jargon?
[DD] ok (see reply to Young's comment as well)
> This alignment you request makes a lot of sense to me. In fact, wherever
> there are one-to-one mappings we should use the framework document
> terminology
[DD] Thanks, I agree.
> I under the impression the customer entity is implicit here, and therefore
[DD] Okay
> That's an option, that implies full trust between every domain control entity
> and the VNO, but other degrees of trust can exist, where a given domain
> control could not want to share the full detail of its underlying topology to
> a VNO.
[DD] Suggest we word the text such that both models can exist. 
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
> nuestra política de envío y recepción de correo electrónico en el enlace
> situado más abajo.
> This message is intended exclusively for its addressee. We only send and
> receive email on the basis of the terms set out at:

---

From: Leeyoung <[email-masked]>
Date: Fri, 20 Jun 2014 19:39:44 +0000

-----Original Message-----
From: Dhruv Dhody 
Sent: Friday, June 20, 2014 12:24 AM
To: Leeyoung; Diego R. Lopez
Cc: [email-masked]; [email-masked]
Subject: RE: [Actn] Regarding draft-lopez-actn-vno-multidomains

Hi Diego and Young, 

> >> The operation and control/management of these multiple networks as 
> >> a single virtualized network.
> >> single
> I think the use-case discussed in 'draft-lopez-actn-vno-multidomains' 
> deals with having many different domains under its control and 
> addresses the need for a global operational view on all these domains. 
> In such context, a single virtualized network is for the operator and 
> there is no customer involved here per se. Each domain would provide 
> some abstraction to the VNO- coordinator in which to create a global network abstraction.
> 

> Thanks for your comments. We'll try to address them in the document as 
> soon as we can. A few replies inlined below...
> 
> > Can we elaborate a bit more regarding the impact of NFV? Maybe 
> > mention especially virtualization of CE and PE devices? Coexistence 
> > of virtualized and non-virtualized network functions etc?
> 
> I'd prefer not to go for specifically mentioning concrete cases unless 
> you see a special aspect to be remarked (if you do, please let's talk about them).
> virtualized functions is a key aspect, and ACTN should definitely be 
> of help for making it easier.
> 
> 
> >>  Figure 2 shows operations hierarchy based on Figure 1. The two 
> >> main ideas are:
> >>
> > Coordinator is VNC while DCN and TN control are PNC?  VNO-I is 
> > VNC-PNC Interface (VPI)?
> 
> This alignment you request makes a lot of sense to me. In fact, 
> wherever there are one-to-one mappings we should use the framework 
> document terminology
[DD] Thanks, I agree.
> 
> > Also I was wondering if there exist another entity customer similar 
> > to the framework document?
> 
[DD] Okay
> That's an option, that implies full trust between every domain control 
> entity and the VNO, but other degrees of trust can exist, where a 
> given domain control could not want to share the full detail of its 
> underlying topology to a VNO.
> Este mensaje se dirige exclusivamente a su destinatario. Puede 
> consultar nuestra política de envío y recepción de correo electrónico 
> en el enlace situado más abajo.
> This message is intended exclusively for its addressee. We only send 
> and receive email on the basis of the terms set out at:

---

From: Leeyoung <[email-masked]>
Date: Fri, 20 Jun 2014 19:42:01 +0000

Hi Dhruv,

For your comment: 

That is a good suggestion. I think a clarifying text would work well. 

Thanks,
Young

-----Original Message-----
From: Dhruv Dhody 
Sent: Friday, June 20, 2014 12:24 AM
To: Leeyoung; Diego R. Lopez
Cc: [email-masked]; [email-masked]
Subject: RE: [Actn] Regarding draft-lopez-actn-vno-multidomains

Hi Diego and Young, 

[DD] Thanks, I agree.
[DD] Okay