Yoav , Kang Xi
if the below two are not goal a.1- If performance or latency on VxLAN is not being monitored and not the goal for individual vCPE a.2 - Also if multiple Instances of vCPE existing at the same time is not to be supported Then whether vCPE is deployed across multiple DC or single DC it makes no difference .Hence I would agree to what is described below . with best regards gaurav ________________________________ From: onap-discuss-boun...@lists.onap.org <onap-discuss-boun...@lists.onap.org> on behalf of Yoav Kluger <yoav.klu...@amdocs.com> Sent: 10 August 2017 03:52:41 To: Kang Xi; onap-discuss@lists.onap.org Subject: Re: [onap-discuss] 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 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 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:image003.jpg@01D3113A.7DB69750] 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.amdocs.com_about_email-2Ddisclaimer&d=DwMFBA&c=uilaK90D4TOVoH58JNXRgQ&r=ebJjFMpXijqZjbZCcbF7yJIq2ES6jM0Q-DEcP-qjjeI&m=92eKrYAeI78xAB2GnnbFkU1K8Io2QkQ-mnqVT3XPDD4&s=gKeYu1eiDqkB66HktmzADnJNYjQ7xY9_d63o61Vj1tA&e=>
_______________________________________________ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
