Subject: Re: [Actn] Regarding draft-kumaki-actn-multitenant-vno

From: "Kenji Kumaki" <[email-masked]>
Date: Fri, 11 Jul 2014 11:15:40 +0900

Hi Dhruv,

Thanks for your comments and sorry for the delayed response.
See in line.

Thanks,
Kenji

> -----Original Message-----
> From: Dhruv Dhody [mailto:[email-masked]]
> Sent: Tuesday, June 17, 2014 1:34 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Actn] Regarding draft-kumaki-actn-multitenant-vno
> 
> Dear Authors,
> 
> Thanks for this document which describe the multi-tenant virtual network
operations use case of ACTN.
> 
> IMO this is especially harder in case of multi-domain core transport
network and a small section maybe added for this.

I'd like to clarify the word 'domain'. Do you use it from routing
perspective?
If yes, normally, carrier networks consist of multiple domains.
I'm not sure what you want to say here?

> Further comments/suggestions for your consideration.
> 
> >Abstract
> >
> >   This document provides a use case that addresses the need for
> >   facilitating virtual network operation: creation and operation of
> >   multi-tenant virtual networks that use the common core network
> >   resources.  This will accelerate a rapid service deployment of new
> >   services, including more dynamic and elastic services, and improve
> >   overall network operations and scaling of existing services.  This
> >   use case addresses the aforementioned needs within a single operator
> >   network.
> 
> You mention 'common core network' and 'single operator network'. It may be
useful to clarify that they may be multi-domain,
> multi-subnet, multi- technology etc.
> 

Actually, 'common core network' means that we provide multiple services on
the single core network, and it is a multi-domain network.

> >1.  Introduction
> >
> >   This document provides a use case that addresses the need for
> >   facilitating virtual network operation: creation and operation of
> >   multi-tenant virtual networks that use the common core network
> >   resources.  This will accelerate a rapid service deployment of new
> >   services, including more dynamic and elastic services, and improve
> >   overall network operations and scaling of existing services.  This
> >   use case supports Abstraction and Control of Transport Networks
> >   (ACTN).  The aim of ACTN is to facilitate virtual network operation,
> >   creation of a virtualized environment allowing operators to view and
> >   control multi-subnet multi-technology networks into a single
> >   virtualized network.  Related documents are:
> >   [I-D.leeking-actn-problem-statement] and
> >   [I-D.ceccarelli-actn-framework] which provide detailed information
> >   regarding this work.
> 
> It should be clarified that the multi-tenant VN using ACTN framework
improves network operations and scaling, the first
> few lines give an impression that just creating VN via existing means
would achieve that.
>
> Also I was thinking, if there is a need to describe multi-tenant or
virtual network from ACTN point of view.

OK. I'll reflect on your comments.

> >3.  Motivation
> >   The characteristics of the multiple services network are as follows:
> >
> 
> Can the current state of the multiple services network described first,
followed by current issues and which of those
> issues do ACTN tackles? IMO this would read better.
>

OK. I'll reflect on your comments.
 
> >4.1.  Service Consolidation
> >
> >   Multi-tenant virtual network operation should support different
> >   services as the tenants that share the common core transport network
> >   resources.  Therefore, it is important to understand the type of
> >   various services and its service requirement.
> >
> >4.2.  VPN Service Consolidation
> >
> >   Network providers have many different service networks such as VPNs
> >   of various types and different QoS requirements.  Within VPNs, there
> >   are several QoS levels.  Some VPN is best-effort VPN while other VPNs
> >   require a strict QoS such as bandwidth guarantee and latency.
> >   Therefore, multi-level VPNs should be supported in multi-tenant
> >   virtual network consolidation.
> 
> But how is this consolidation of service? You also mention network
consolidation... can this be clarified?
> 
> Or do you think this would be similar to cargo consolidation where smaller
shipments are assembled and shipped together?

We have two approaches for network consolidation.
One is the horizontal network consolidation that we create a multiple domain
network(multi-area/multi-domain network). Here is the conventional network
architecture. The other is the vertical network consolidation that we create
a network slice vertically on the common core network.

Here, our approach shows the latter.

> >4.3.  Network Wholesale Service
> >
> >   Network providers want to provide a network resource (i.e. a network
> >   slice) to ISPs.  In this case, the network provider must guarantee
> >   the SLA to each ISP.  There may be different level of SLA as well as
> >   different level of virtual network granularity for each ISP.  The ISP
> >   should be given its virtual network(s) as well as an independent
> >   domain control of allocated virtual network(s).
> 
> I think this is an important point, and we should highlight that this a
bit more as a clear objective of ACTN and how
> this cannot be done using existing mechanism.
>

In case that we provide a network to an ISP, which means the ISP has a
different AS and basically ISP does not want to change own network policy,
we can deploy carriers' carriers in RFC4364. However, ISPs need to change
their network policy and run LDP at an edge router although they deploy just
IP. Additionally, they (network architects at ISP) need to transfer MPLS
knowledge to operators. 
 
> >5.  Multi-tenant Virtual Network Operation Coordination
> >
> >   The following Figure 2 depicts a functional control architecture that
> >   shows the need to support virtual networks to a number of different
> >   service networks that share the common core network resources.
> >
> >
> >
> >                           +-----------------+
> >                           |  Multi-tenant   |
> >                           | VN Coordination |
> >      +-----------+        +-----------------+    +-----------+
> >      | Service A |-+           |   |   |         | Service A |-+
> >      |  Control  |B|-+         |   |   |         |  Control  |B|-+
> >      +-----------+ |C|---------|   |   |---------+-----------+ |C|
> >        +-----------+ |             |               +-----------+ |
> >          +-----------+     +---------------+         +-----------+
> >                            |Core Transport |
> >             /------\       |Network Control|      /------\
> >           //        \\     +---------------+    //        \\
> >          |  Service A |            |           |  Service A |
> >           \\        //        ----------        /\        //
> >              ------   \   ////          \\\\   /   ------
> >         /------\       \||                  ||/       /------\
> >       //        \\     |     Core Transport   |     //        \\
> >      |  Service B |----|                      |----|  Service B |
> >       \\        //      ||       Network    ||      \\        //
> >         \------/          \\\\          ////          \------/
> >             /------\    /     ----------    \     /------\
> >           //        \\ /                     \  //        \\
> >          |  Service C |                       \|  Service C |
> >           \\        //                          \\        //
> >              ------                                ------
> >
> >
> 
> Is there a reason for 2 sets of service control(ers) in this figure?
>

I have no particular reason for it.

> 
> >
> >   7.  As a number of services carried on the common transport network
> >       sharing a common network resource, operational independence for
> >       each service has to be guaranteed as if each service owns its
> >       dedicated resources.
> >
> 
> Shouldn't this be 'each service owns its dedicated virtual resources.'?
>

Actually, I think each service should have the dedicated virtual resources. 
Because we need to share the common network resources from operational
perspective.
 
> Thanks Again!
> 
> Regards,
> Dhruv
> 
> 
> ---------------------------------------------------------------
> Dhruv Dhody
> System Architect,
> Huawei Technologies India Pvt. Ltd.,
> Banagalore
> Mobile: +91-9845062422
> 
> _______________________________________________
> ACTN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/actn

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 11 Jul 2014 08:46:09 +0530

Hi Kenji,

Thanks for your reply, see inline..

(snip)

> I'm not sure what you want to say here?

IMO particular attention needs to be paid to the multi-domain case,
where ACTN can facilitate virtual network operation via the creation
of a single virtualized network and these domains may be technology,
administrative or vendor specific (vendor islands). A few more words
on these lines in the introduction can be added.

> the single core network, and it is a multi-domain network.

as noted above, current text does not mention multi-domain at all, and
i feel a few lines can be useful to clarify it.

(snip)

> Here, our approach shows the latter.

So if i understand you correctly, this is like Vertical integration
(or consolidation) in business sense, as some very different services
are consolidated and offered together?

> IP. Additionally, they (network architects at ISP) need to transfer MPLS

Agree.

> I have no particular reason for it.

Then i would suggest we make it just one. :)

> Because we need to share the common network resources from operational

A rewording to "...each service owns its dedicated virtual resources"
would be better then.

---

From: "Kenji Kumaki" <[email-masked]>
Date: Fri, 11 Jul 2014 13:23:12 +0900

Hi Dhruv,

See in line.

Thanks,
Kenji

> IMO particular attention needs to be paid to the multi-domain case, where ACTN can facilitate virtual network operation
> via the creation of a single virtualized network and these domains may be technology, administrative or vendor specific
> (vendor islands). A few more words on these lines in the introduction can be added.
> 

Understand.

> > Actually, 'common core network' means that we provide multiple
> > services on the single core network, and it is a multi-domain network.
> 
> as noted above, current text does not mention multi-domain at all, and i feel a few lines can be useful to clarify it.
> 

I'll clarify it.

> > One is the horizontal network consolidation that we create a multiple
> > domain network(multi-area/multi-domain network). Here is the
> > conventional network architecture. The other is the vertical network
> > consolidation that we create a network slice vertically on the common core network.
> >
> So if i understand you correctly, this is like Vertical integration (or consolidation) in business sense, as some very
> different services are consolidated and offered together?
> 

Yes, our approach is the vertical consolidation. I think it's not business sense but technical one, as the horizontal consolidation has some issues for minimizing an impact on routing/signaling process failures.

> > different AS and basically ISP does not want to change own network
> > policy, we can deploy carriers' carriers in RFC4364. However, ISPs
> > need to change their network policy and run LDP at an edge router
> > although they deploy just IP. Additionally, they (network architects
> > at ISP) need to transfer MPLS knowledge to operators.
> 
> Agree.
> 
> >

OK.

> A rewording to "...each service owns its dedicated virtual resources"

OK.