Ramesh, Thanks for more data in the slide 4. However this does not really answer my question. The question is which abstraction(s), you suggest, should be supported by the “external controller” For example, which (types of) operations the “external controller“ is supposed to support? A good example is slide 16 showing that the SD-WAN controller supports Presto and Adagio in case of MEF, which already provides some hints. There may be several additional abstractions supported by the SD-WAN controller – all right, just need to list them. Then let me ask same question about so called “External Controller”: what operations the “external controller“ is supposed to support? The list of forums does not help. Is it slide 6 to help? Probably not. What is “Domain Controller” e.g. in case of the RAN domain? What kind of RAN abstraction it is assumed to support? Where is it defined?
Thanks Vladimir From: Nagarajan, Ramesh A. [mailto:[email protected]] Sent: Sunday, October 15, 2017 8:14 AM To: Vladimir Yanover (vyanover) <[email protected]>; Alla Goldner <[email protected]>; [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: RE: [Onap-arc] [External] Re: [Onap-usecasesub] [onap-tsc] External controller support in BeijingRelease Hi All, Please find the updated slides on the link below https://wiki.onap.org/display/DW/ONAP+external+controller+integration<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_ONAP-2Bexternal-2Bcontroller-2Bintegration&d=DwMFAg&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=z7a9RxCnpCTOr5e73KITk87n8JtmCnBxUU_VZbci5do&m=SBg6M3Xap1LwunGQ0skBzsT68nE6Li1oicCCjmYZnio&s=vYNEnwgQfGEKw7pH--2mNwnqh9qr9zKSRitKXestch8&e=> Vladimir, Per your question, please find some current/emerging standards for domain abstractions in slide 4 and other parts of the deck. Ramesh. From: Vladimir Yanover (vyanover) [mailto:[email protected]] Sent: Sunday, October 15, 2017 12:13 AM To: Nagarajan, Ramesh A. <[email protected]<mailto:[email protected]>>; Alla Goldner <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: [Onap-arc] [External] Re: [Onap-usecasesub] [onap-tsc] External controller support in BeijingRelease Dear Colleagues, The question “what is the abstraction of external controller” is another form of the question “what the external controller is” or, if you will, “what this discussion is about”. Until this question is answered, how anything can be done about the “external controller”? The original presentation on SD-WAN refers to several particular abstractions of the SD-WAN controller that should be covered. If these abstractions are well defined (I did not check), for SD-WAN that’s enough. However extending this further, necessarily raises the question how we define the class of controllers to be covered i.e. which abstraction we are going to follow. Thanks Vladimir From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Nagarajan, Ramesh A. Sent: Thursday, October 12, 2017 11:51 PM To: Alla Goldner <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [Onap-arc] [External] Re: [Onap-usecasesub] [onap-tsc] External controller support in BeijingRelease Hi All, Thanks for all the good questions and suggestions on this proposal. As promised, we will share updated slides tomm. But to provide some brief comments below on a couple of the questions/suggestions. - What is the abstraction to the external controller: The answer depends on the service domain, don’t think there is any universal abstraction. There is work already in the industry to define abstractions for specific domains such as sd-wan, sd-access, sd-optical etc., and we will share some of these references but some have been shared by others already - Single or multiple integration points: What we have described via the requirements is the needed interaction/information sharing between the ONAP components and the external controller. This interaction could happen over a single or multiple integration points. I think this is a discussion/decision with the architecture team and broader community. Ramesh. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Alla Goldner Sent: Thursday, October 12, 2017 1:58 AM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: [External] Re: [Onap-usecasesub] [onap-tsc] [Onap-arc] External controller support in BeijingRelease Hi Maopeng, all, I let External Controller functionality proposal answer the raised questions. As to the project’s impact, as we are not talking about SD-WAN’s –only External Controller now, I believe that also project impacts should be taken separately not within the scope of SD-WAN only, rather generalized. Best regards, Alla Goldner Open Network Division Amdocs Technology [cid:[email protected]] From: [email protected]<mailto:[email protected]> [mailto:[email protected]] Sent: Thursday, October 12, 2017 4:27 AM To: Alla Goldner <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: 答复: Re: [onap-tsc] [Onap-arc] External controller support in BeijingRelease hi Alla There are projects impact in the wiki. Could we refer it? thanks. https://wiki.onap.org/pages/viewpage.action?pageId=11929755<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_pages_viewpage.action-3FpageId-3D11929755&d=DwMGaQ&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=z7a9RxCnpCTOr5e73KITk87n8JtmCnBxUU_VZbci5do&m=J7Hvx5Zzge-ShQr6Gncypd8b4Ly-PT04qGx9oveCvcI&s=n4vsLgVDwyf5kBtMasj-N4hZXRCYLKgMpajYcWr19as&e=> Interface appearance: [Image removed by sender.] Project Impact: [Image removed by sender.] BR Maopeng 原始邮件 发件人： <[email protected]<mailto:[email protected]>>; 收件人： <[email protected]<mailto:[email protected]>>; <[email protected]<mailto:[email protected]>>; 抄送人： <[email protected]<mailto:[email protected]>>; <[email protected]<mailto:[email protected]>>; 日 期 ：2017年10月10日 13:10 主 题 ：Re: [onap-tsc] [Onap-arc] External controller support in BeijingRelease Thanks, Pam, Here is the updated list with also one typo corrected. 1. AAI, incl. ESR 2. SDC, VNF SDK, Modelling 3. SO 4. VID 5. External API 6. DCAE, HOLMES, Policy, CLAMP Best regards, Alla Goldner Open Network Division Amdocs Technology [cid:[email protected]] From: DRAGOSH, PAMELA L (PAM) [mailto:[email protected]] Sent: Monday, October 09, 2017 7:05 PM To: Alla Goldner <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> P <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [Onap-arc] External controller support in Beijing Release Alla, If you intend to use the External Controller for any control loop use cases then you will need Policy. With that being said, the request from the Policy team is a single common Controller SDK to be implemented by all controllers for performing any type of action on a VM/VNF. And as simplistic an API as possible. The current API implementations for SO/APPC/VFC are overly complicated and require too much interaction with A&AI. Thanks, Pam From: <[email protected]<mailto:[email protected]>> on behalf of Alla Goldner <[email protected]<mailto:[email protected]>> Date: Monday, October 9, 2017 at 11:50 AM To: "[email protected] P<mailto:[email protected]%20P>" <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [Onap-arc] External controller support in Beijing Release Hi all, We (Usecase subcommittee) would like to initiate a discussion with a different involved projects on potential implementation of External controller in Beijing Release. Next week, we need to present and get a view from the following affected projects: 1. AAI, ESI 2. SDC, VNF SDK 3. Modelling 4. SO 5. VID 6. External API 7. DCAE, HOLMES 8. CLAMP And, of course, from the architecture and modelling subcommittees. (Ramesh, please add any potentially affected projects I may have forgotten). One way is to schedule a new meeting. The alternative way is to ask Chris for Architecture subcommittee meeting’s time and discuss it there ☺ What do you think? Chris, is there any possibility to host this discussion next week? Best regards, Alla Goldner Open Network Division Amdocs Technology [cid:[email protected]] 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=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=jwTiArcEj6aUX0HjV0M3dT12gUtk7rC07xpgpVZkS_4&m=BPpbIMtWz3IWAh_XsuepRoZss7N0GWC9-v6pYEh_unk&s=r-g9j6tieoh0RKObysLSW_mLXqTV4Ai1PR7UMHXazGE&e=> 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=DwMGaQ&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=z7a9RxCnpCTOr5e73KITk87n8JtmCnBxUU_VZbci5do&m=J7Hvx5Zzge-ShQr6Gncypd8b4Ly-PT04qGx9oveCvcI&s=xflgtF4R2pcICMg39qO6r1l24SQFXeAcc6TLdEkC7XI&e=> 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=DwMGaQ&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=z7a9RxCnpCTOr5e73KITk87n8JtmCnBxUU_VZbci5do&m=J7Hvx5Zzge-ShQr6Gncypd8b4Ly-PT04qGx9oveCvcI&s=xflgtF4R2pcICMg39qO6r1l24SQFXeAcc6TLdEkC7XI&e=> ________________________________ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. ______________________________________________________________________________________ www.accenture.com<http://www.accenture.com>
_______________________________________________ ONAP-TSC mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-tsc
