Hi Yoav,

The statement is certainly valid within the context of the assumption. I'm 
pleased that there is no changes needed for the R1 deliverables.

Regards,
Kang

From: Yoav Kluger [mailto:yoav.klu...@amdocs.com]
Sent: Wednesday, August 09, 2017 18:23
To: Kang Xi <kang...@huawei.com>; onap-discuss@lists.onap.org
Cc: Yunxia Chen <helen.c...@huawei.com>; Pawłowski Michał 1 - Korpo 
<michal.pawlows...@orange.com>; FREEMAN, BRIAN D <bf1...@att.com>
Subject: RE: vCPE: Consider multi-cloud support in R2

Kang, all,

Sorry could not attend the meeting (which collided with the ARC meeting).

I would propose to not view the connectivity between clouds as a problem, or 
use case, ONAP needs to solve. Service provides who have deployed multiple 
clouds have typically also established connectivity between them, in most cases 
via some type of a L2 VPN. When ONAP instantiates VNFs there is an assumption 
that it can then communicate with them, e.g. for configuration or closed loop 
operations, over an OAM overlay network. We do not bother showing how this OAM 
network is routed, and in particular how SDNC, as an example, can communicate 
with a VNF which happens to be instantiated in a remote DC. We assume whatever 
underlay is need is in place which allows communicating with all VNFs over the 
one OAM network.

Similarly, if two VNFs are assumed to communicate over regular IP networking 
(not to be confused with service chaining), then, without loss of generality, 
we can showcase them in one DC, assuming that if in real life they were to be 
instantiated in two DCs, then the inter-dc connectivity already in place would 
enable them to communicate just as well.

The other alternative would be that we would have to showcase each VNF in a 
separate DC - to "make sure" the use case works under any deployment scenario. 
This obviously does not make sense, and fortunately is also not needed for the 
reasons sated above.

I would therefore submit that the vCPE use case, which instantiates all its 
VNFs in a single DC, is sufficient to showcase ONAP's capability to instantiate 
and manage a vCPE use case under any deployment.

Thanks,
Yoav Kluger
Amdocs Technology
+1(201)912-7294
+972-54-4850278
[amdocs-a]

From: Kang Xi [mailto:kang...@huawei.com]
Sent: Tuesday, August 08, 2017 11:37 AM
To: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>
Cc: Yunxia Chen <helen.c...@huawei.com<mailto:helen.c...@huawei.com>>; 
Pawłowski Michał 1 - Korpo 
<michal.pawlows...@orange.com<mailto:michal.pawlows...@orange.com>>; Yoav 
Kluger <yoav.klu...@amdocs.com<mailto:yoav.klu...@amdocs.com>>; FREEMAN, BRIAN 
D <bf1...@att.com<mailto:bf1...@att.com>>
Subject: vCPE: Consider multi-cloud support in R2

Hi All,

During the meeting "[integration] vCPE for R1: Support multiple clouds or not?" 
(Aug. 8 11:00-11:25am EST), the attendees unanimously concluded to leave the 
support for multiple clouds to the next release. For R1, the release 
implementation will only target a single cloud set up.

The rationale behind the above conclusion is that multi-cloud support, while 
technically feasible, would need quite some discussions to decide on multiple 
issues including lab set up, network set up, work flow design, etc. Adding it 
to R1 would further tighten the R1 schedule.

The list of attendees is shown below:

[cid:image002.jpg@01D311F8.BD2163C0]
Regards,
Kang

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
_______________________________________________
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Reply via email to