Ramesh, It looks like you misunderstood my comments; my apology if it was not clear enough. The slide 4 is titled “Sample Standards/Industry Initiatives for Domain Abstraction”. I read it as there are ongoing activities on abstractions for certain domains, which presumably provides for business rationale for the proposed project. It does not say anything about domain controller abstraction(s) that should be supported in R2. Maybe you had in mind that all (or some of) abstractions listed in the slide 4, should be supported in R2? If yes, I suggest to write it down. I cannot read minds. What is not written, does not exist.
Another point is that the slide 4 appears under “Business Drivers and Rationale”. The abstraction (or set of abstractions) to be supported is however a requirement. There is a difference between the rationale and requirements, isn’t it? To summarize, there should be a requirements-style part that refers to the abstraction (or set of abstractions) to be supported in the project. It should be an exhaustive list because support of “every imaginable controller” is hardly possible. This requirements-style part can be created e.g. by modification of the slide 4 as follows Business Drivers and Rationale The Domain abstractions to be supported (pending possible down selection) · Sample Standards/Industry Initiatives for Domain Abstraction · MEF Presto Emerging standards to define interface between LSO and network domain specific provisioning, monitoring · MEF SD-WAN Presto Interface between LSO/SOF and SD-WAN Controller (Understanding SD-WAN Managed Services: Service Components, MEF LSO Reference Architecture, and Use Cases, see also slide 11) · VOLTHA abstraction for SD-Access covering GPON today but plan to extend to DSL etc., (see also slide 10) · … etc. Vladimir From: Nagarajan, Ramesh A. [mailto:ramesh.a.nagara...@accenture.com] Sent: Monday, October 16, 2017 6:50 PM To: Vladimir Yanover (vyanover) <vyano...@cisco.com>; Alla Goldner <alla.gold...@amdocs.com>; zhang.maope...@zte.com.cn Cc: onap-...@lists.onap.org; onap-usecase...@lists.onap.org; onap-tsc@lists.onap.org Subject: RE: [Onap-arc] [External] Re: [Onap-usecasesub] [onap-tsc] External controller support in BeijingRelease Vladimir, I am not sure if you realized that the list on slide 4 is hyperlinked to the standard/industry initiative. Each of this has more detail on the specific operations/APIs, did not want to regurgitate it here. MEF material is, however, not open to non-MEF members. But it seems there is an official liason now between ONAP and MEF, so perhaps we can get the detailed APIs ? (not sure who the liason is from ONAP side ..). Ramesh. From: Vladimir Yanover (vyanover) [mailto:vyano...@cisco.com] Sent: Monday, October 16, 2017 6:19 AM To: Nagarajan, Ramesh A. <ramesh.a.nagara...@accenture.com<mailto:ramesh.a.nagara...@accenture.com>>; Alla Goldner <alla.gold...@amdocs.com<mailto:alla.gold...@amdocs.com>>; zhang.maope...@zte.com.cn<mailto:zhang.maope...@zte.com.cn> Cc: onap-...@lists.onap.org<mailto:onap-...@lists.onap.org>; onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>; onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org> Subject: RE: [Onap-arc] [External] Re: [Onap-usecasesub] [onap-tsc] External controller support in BeijingRelease 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:ramesh.a.nagara...@accenture.com] Sent: Sunday, October 15, 2017 8:14 AM To: Vladimir Yanover (vyanover) <vyano...@cisco.com<mailto:vyano...@cisco.com>>; Alla Goldner <alla.gold...@amdocs.com<mailto:alla.gold...@amdocs.com>>; zhang.maope...@zte.com.cn<mailto:zhang.maope...@zte.com.cn> Cc: onap-...@lists.onap.org<mailto:onap-...@lists.onap.org>; onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>; onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org> 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:vyano...@cisco.com] Sent: Sunday, October 15, 2017 12:13 AM To: Nagarajan, Ramesh A. <ramesh.a.nagara...@accenture.com<mailto:ramesh.a.nagara...@accenture.com>>; Alla Goldner <alla.gold...@amdocs.com<mailto:alla.gold...@amdocs.com>>; zhang.maope...@zte.com.cn<mailto:zhang.maope...@zte.com.cn> Cc: onap-...@lists.onap.org<mailto:onap-...@lists.onap.org>; onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>; onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org> 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: onap-arc-boun...@lists.onap.org<mailto:onap-arc-boun...@lists.onap.org> [mailto:onap-arc-boun...@lists.onap.org] On Behalf Of Nagarajan, Ramesh A. Sent: Thursday, October 12, 2017 11:51 PM To: Alla Goldner <alla.gold...@amdocs.com<mailto:alla.gold...@amdocs.com>>; zhang.maope...@zte.com.cn<mailto:zhang.maope...@zte.com.cn> Cc: onap-...@lists.onap.org<mailto:onap-...@lists.onap.org>; onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>; onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org> 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: onap-usecasesub-boun...@lists.onap.org<mailto:onap-usecasesub-boun...@lists.onap.org> [mailto:onap-usecasesub-boun...@lists.onap.org] On Behalf Of Alla Goldner Sent: Thursday, October 12, 2017 1:58 AM To: zhang.maope...@zte.com.cn<mailto:zhang.maope...@zte.com.cn> Cc: onap-...@lists.onap.org<mailto:onap-...@lists.onap.org>; onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>; onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org> 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:image001.png@01D34733.3372EBB0] From: zhang.maope...@zte.com.cn<mailto:zhang.maope...@zte.com.cn> [mailto:zhang.maope...@zte.com.cn] Sent: Thursday, October 12, 2017 4:27 AM To: Alla Goldner <alla.gold...@amdocs.com<mailto:alla.gold...@amdocs.com>> Cc: pdrag...@research.att.com<mailto:pdrag...@research.att.com>; onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>; onap-...@lists.onap.org<mailto:onap-...@lists.onap.org>; onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org> 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 原始邮件 发件人: <alla.gold...@amdocs.com<mailto:alla.gold...@amdocs.com>>; 收件人: <pdrag...@research.att.com<mailto:pdrag...@research.att.com>>; <onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>>; 抄送人: <onap-...@lists.onap.org<mailto:onap-...@lists.onap.org>>; <onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>>; 日 期 :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:image001.png@01D34733.3372EBB0] From: DRAGOSH, PAMELA L (PAM) [mailto:pdrag...@research.att.com] Sent: Monday, October 09, 2017 7:05 PM To: Alla Goldner <alla.gold...@amdocs.com<mailto:alla.gold...@amdocs.com>>; onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org> P <onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>> Cc: onap-...@lists.onap.org<mailto:onap-...@lists.onap.org>; onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org> 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: <onap-arc-boun...@lists.onap.org<mailto:onap-arc-boun...@lists.onap.org>> on behalf of Alla Goldner <alla.gold...@amdocs.com<mailto:alla.gold...@amdocs.com>> Date: Monday, October 9, 2017 at 11:50 AM To: "onap-tsc@lists.onap.org P<mailto:onap-tsc@lists.onap.org%20P>" <onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>> Cc: "onap-...@lists.onap.org<mailto:onap-...@lists.onap.org>" <onap-...@lists.onap.org<mailto:onap-...@lists.onap.org>>, "onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>" <onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>> 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:image003.png@01D34733.3372EBB0] 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 ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc