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