Thanks Daniel. Could you please clarify some of my follow-up queries:
1. Could you help me with the notion of "Subscribers" ? Why & for what
use-case?
- Would AAI hold this information of what subscribers are connected
to which instance of NS ?
- Can multiple subscribers share same NS? Would this information be
exported / connected to external systems like accounting / BSS ?
2. Moreover, I would like to understand the difference between Virtual
Network Function ( during deploy time at VID ) and Virtual Function (
during design time at SDC ). Why there is another layer called VNF on top
of VF ?
3. Robot-VM is actually doing many stuffs including letting AAI know
about the SDC models and letting AAI know about Openstack tenant details (
by using APIs ). Is there any WIP to automate the same?
- Why there is no communication b/w SDC and AAI, as soon a network
service / VF is certified & distributed by operator?
4. On a separate thread, Catherine had mentioned that, there is a file
called cloud-config.json which can be used to specify regions / tenants
within openstack. I believe that is for MSO. If I want to deploy NS on
selected region / tenant in VID, how am I supposed to achieve it?
- I also see something termed as "LCP region". Could you please
explain more about this or Please point me to some resource in
Wiki where I
can read more about this.
BR,
Viswa
On Thu, Jun 1, 2017 at 11:29 PM, ROSE, DANIEL V <[email protected]> wrote:
> To Dhananjay,
>
>
>
> 1. For configuration of devices yes, but the demos don’t use them
> because the virtual functions are not configured they are hard coded. A
> real vnf would need to have yang.
>
> 2. For the demos, nothing.
>
> 3. 3a is a one time thing, it does stuff like populate vim stuff
> (region and tenant) the expectation in a real cloud is youd fill those in
> as regions are created. It also creates a subscriber which is basically a
> customer and would presumably be done upstream in a bss / oss / wherever
> when they are first created. 3b, 3c and 3e I think there is an enhancement
> in the works to allow the whole thing to be instantiated at once, mso can
> confirm. It may already be possible, since we do have the model we know the
> steps of everything. 3d is a bit of an odd child, its data that is needed
> to complete the instantiation but which is not provided in the model.
> Internally we use external systems for a lot of it (ipam etc) and the
> preload is just what is left of that. The rebase we are testing now should
> remove the need for this as this info is asked for in vid. 3f mso will do,
> there is a story open for that.
>
> 4. 3b, 3c, 3e are already done in SO (nee MSO), 3a is outside
> process (you don’t create tenants in openstack when calling nova create
> server for instance) and 3d and 3f are temporary things that should be
> going away soon.
>
>
>
> To Viswa,
>
> This decomposition is already done, just not shown in the demo so well,
> the model and the SO do know the order. And MSO is involved (see response
> to Dhananjay above).
>
>
>
>
>
> Thanks,
>
> Daniel Rose
>
> ECOMP / ONAP
>
> com.att.ecomp
>
> 732-420-7308
>
>
>
> *From:* Viswa KSP [mailto:[email protected]]
> *Sent:* Thursday, June 01, 2017 1:43 PM
> *To:* Dhananjay Pavgi <[email protected]>
> *Cc:* [email protected]; ROSE, DANIEL V <[email protected]>
> *Subject:* RE: [onap-discuss] Why there is a manual step before deploying
> a distributed / certified network service?
>
>
>
> Thanks Daniel. I do have a follow up query. Adding to what Dhananjay has
> quoted, should the decomposition of network service be taken care
> automatically by service orchestrator ?
>
>
>
> If we see Open -O or XOS/CORD, the story remains same . We provide NSD and
> the master orchestrator takes the burden of decomposing network service
> requirements, identify dependencies w.r.t infrastructure ( NF -O ) and
> network ( SDN-O ) , along with life cycle work flow.
>
>
>
> Is there any reason ( architectururaly ) , why MSO isn't involved here ?
>
>
>
> BR,
>
> Viswa
>
>
>
> On Jun 1, 2017 9:47 PM, "Dhananjay Pavgi" <[email protected]>
> wrote:
>
> Thanks, Daniel. Few related questions as below:
>
>
>
> 1. When it comes to “Service Instantiation” on VNFs; don’t we need
> Yang models.
>
> 2. i.e. what does finally SDNC send as a payload over Netconf?
>
> 3. Also, our understanding of APIs being called is as below (which
> is right now manual activity in vFW demo):
>
> a. Run demo.sh init script (We will share these details but
> essentially it invokes AAI REST APIs)
>
> b. Service Instance Create
>
> c. VNF Create
>
> d. Run demo.sh preload (We will share these details but essentially
> it invokes SDNC REST APIs)
>
> e. VF Module Create
>
> f. Run demo.sh appc script (We will share these details but
> essentially it invokes APPC REST APIs)
>
> 4. Ideally, 3a through 3f above should be handled by “Service
> Orchestrator”, right?
>
>
>
> thanks & regards,
>
> Dhananjay Pavgi
>
> Mobile : +91 98220 22264
>
> [image: cid:[email protected]] [image:
> ONAP_logo_Sig]
>
> www.techmahindra.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.techmahindra.com_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=wj-P9f9XBIxdpyIqrRsIg4InkRWIvIwz0MSTL3reH3M&s=eKSSa5svrJJZIBjHGiq0bOAK3KpUelMy_gIEFUd7aXM&e=>
> Platinum Member. Visit : http://www.onap.org
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.onap.org_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=wj-P9f9XBIxdpyIqrRsIg4InkRWIvIwz0MSTL3reH3M&s=XGAJqN0REk91XmBABHIg5_3B4vOdE6XO9tZMP59_dZo&e=>
>
>
>
> *From:* [email protected] [mailto:onap-discuss-bounces@
> lists.onap.org] *On Behalf Of *ROSE, DANIEL V
> *Sent:* Thursday, June 01, 2017 7:54 PM
> *To:* Viswa KSP <[email protected]>; [email protected]
> *Subject:* Re: [onap-discuss] Why there is a manual step before deploying
> a distributed / certified network service?
>
>
>
> The demo is specifically just a demo. So the stuff in the demo like the
> robot scripts will not work for other vnfs. The mechanisms used in the
> scripts will work with any vnfs however.
>
>
>
> To give you an example, preload command calls sdnc rest api that loads
> info like IPs to sdnc so that when you go to vid and instantiate a vnf sdnc
> knows what data to use. You can call that api yourself to fill in your
> specific parameters for ANY vnf ( you can add a call to the DG to make a
> call out to any external system via rest instead of doing the preload
> also). In the rebase code VID has the option to provide those preloads as
> part of the GUI to make it a bit easier but even though the flow changes
> the fact that it applies to all VNFs does not change.
>
>
>
> Thanks,
>
> Daniel Rose
>
> ECOMP / ONAP
>
> com.att.ecomp
>
> 732-420-7308
>
>
>
> *From:* [email protected] [mailto:onap-discuss-bounces@
> lists.onap.org <[email protected]>] *On Behalf Of *Viswa
> KSP
> *Sent:* Thursday, June 01, 2017 4:50 AM
> *To:* [email protected]
> *Subject:* [onap-discuss] Why there is a manual step before deploying a
> distributed / certified network service?
>
>
>
> Dear All,
>
>
>
> We are trying to follow the steps as per tutorial to bring demo vFirewall
> Network service.
>
> While the steps before deploy operation ( i.e creation of license model,
> design-test-certify cycle for VSP, VF & NS and finally distributing NS for
> production ) seems to be generic & acceptable for other VNFs, the step for
> running demo.sh in robot VM to enable "Deploy" in VID seems to very
> specific to vFirewall NS.
>
>
>
> I would like to understand if this manual step is expected in any other
> NS? What if we wanna customize the work-flow i.e say I want to just design
> my NS and just deploy it right away ( without other steps as per demo
> work-flow ) , how should I go-about in achieving this?
>
>
>
> On a very high-level, I would like to know how much we can customize ONAP ?
>
>
>
> BR,
>
> Viswa
>
> ============================================================
> ================================================================
>
> Disclaimer: This message and the information contained herein is
> proprietary and confidential and subject to the Tech Mahindra policy
> statement, you may review the policy at http://www.techmahindra.com/
> Disclaimer.html
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.techmahindra.com_Disclaimer.html&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=wj-P9f9XBIxdpyIqrRsIg4InkRWIvIwz0MSTL3reH3M&s=OA8rnrS-dBDPZLs0KDL3htkm1D9AsYCaCxZoSDkaViw&e=>
> externally http://tim.techmahindra.com/tim/disclaimer.html
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__tim.techmahindra.com_tim_disclaimer.html&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=wj-P9f9XBIxdpyIqrRsIg4InkRWIvIwz0MSTL3reH3M&s=mOiRMi1aNG1XHwE9Vf78B94NGLAGHOKf_Iy5mdLlchU&e=>
> internally within TechMahindra.
>
> ============================================================
> ================================================================
>
>
_______________________________________________
onap-discuss mailing list
[email protected]
https://lists.onap.org/mailman/listinfo/onap-discuss
