<div dir="ltr"><div>Hi All,</div><div><br></div><div>I’m newbie to Openstack, so I want to clarify how OpenStack can implement ETSI NFV Architecture.</div><div><br></div><div>The concept of Advanced service looks like Network Service in ETSI NFV Architecture as shown in Figure 3 below:</div>
<div><a href="http://docbox.etsi.org/ISG/NFV/Open/Published/gs_NFV002v010101p.pdf">http://docbox.etsi.org/ISG/NFV/Open/Published/gs_NFV002v010101p.pdf</a></div><div><br></div><div>As the functional role, VNF (Virtualized Network Function) may be corespondent to Logical Service Instance.</div>
<div>However, in ETSI NFV Architecture, VNF is composed of VNFC (VNF Component) or VDU (Virtual Deployment Unit) and each VNFC or VDU instance is deployed as a VM.</div><div>These VNFC or VDU instances are connected by logical or physical network links in a manner of a kind of service chaining, then a VNF instance is created.</div>
<div>In the same manner, Network Service is created from one or multiple VNF(s).</div><div><br></div><div>My question is:</div><div>Is it possible that the current OpenStack components realize an advanced service in the above manner?</div>
<div>Meaning, an advanced service is composed of hierarchical multiple VMs.  </div><div><br></div><div>All the best,</div><div>Kenichi</div><div class="gmail_extra"><br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
From: Dmitry [mailto:<a href="mailto:meytin@gmail.com">meytin@gmail.com</a>]<br>
Sent: Thursday, May 22, 2014 5:40 PM<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit<br>
<br>
Hi Isaku,<br>
Thank you for the updated link. I'n not sure where from I get the previous one, probably from the direct Google search.<br>
If we're talking about NFV Mano, it's very important to keep NFVO and VNFM as a separate services, where VNFM might be (and probably will be) supplied jointly with a vendor's specific VNF.<br>
In addition, it's possible that VNFC components will not be able to be placed on the same machine - anti-affinity rules.<br>
Talking in NFV terminology, we need to have a new OpenStack Services which (from what I've understood from the document you sent) is called Adv Service and is responsible to be:<br>
1) NFVO - which is using Nova to provision new Service VMs and Neutron to establish connectivity and service chaining<br>
2) Service Catalog - to accommodate multiple VNF services. Question: the same problem exists with Trove which need a catalog for multiple concrete DB implementations. Do you know which solution they will take for Juno?<br>

2) Infrastructure for VNFM plugins - which will be called by NFVO to decide where Service VM should be placed and which LSI should be provisioned on these Service VMs.<br>
<br>
This flow is more or less what was stated by NFV committee.<br>
<br>
Please let me know what you think about this and how far is that from what you planed for Service VM.<br>
In addition, I would happy to know if Service VM will be incubated for Juno release.<br>
<br>
Thank you very much,<br>
Dmitry<br>
<br>
<br>
<br>
On Thu, May 22, 2014 at 9:28 AM, Isaku Yamahata <<a href="mailto:isaku.yamahata@gmail.com">isaku.yamahata@gmail.com</a>> wrote:<br>
<br>
<br>
        On Wed, May 21, 2014 at 10:54:03AM +0300,<br>
        Dmitry <<a href="mailto:meytin@gmail.com">meytin@gmail.com</a>> wrote:<br>
<br>
        > HI,<br>
<br>
        Hi.<br>
<br>
<br>
        > I would happy to get explanation of what is the difference between Adv<br>
<br>
        > Service Management<<a href="https://docs.google.com/file/d/0Bz-bErEEHJxLTGY4NUVvTzRDaEk/edit" target="_blank">https://docs.google.com/file/d/0Bz-bErEEHJxLTGY4NUVvTzRDaEk/edit</a>>from<br>
        > the Service VM<br>
<br>
        The above document is stale.<br>
        the right one is<br>
        <a href="https://docs.google.com/document/d/1pwFVV8UavvQkBz92bT-BweBAiIZoMJP0NPAO4-60XFY/edit?pli=1" target="_blank">https://docs.google.com/document/d/1pwFVV8UavvQkBz92bT-BweBAiIZoMJP0NPAO4-60XFY/edit?pli=1</a><br>

        <a href="https://docs.google.com/document/d/1ZWDDTjwhIUedyipkDztM0_nBYgfCEP9Q77hhn1ZduCA/edit?pli=1#" target="_blank">https://docs.google.com/document/d/1ZWDDTjwhIUedyipkDztM0_nBYgfCEP9Q77hhn1ZduCA/edit?pli=1#</a><br>

        <a href="https://wiki.openstack.org/wiki/ServiceVM" target="_blank">https://wiki.openstack.org/wiki/ServiceVM</a><br>
<br>
        Anyway how did you find the link? I'd like to remove stale links.<br>
<br>
<br>
        > and NFVO<br>
        > orchestration<<a href="http://www.ietf.org/proceedings/88/slides/slides-88-opsawg-6.pdf" target="_blank">http://www.ietf.org/proceedings/88/slides/slides-88-opsawg-6.pdf</a>>from<br>
<br>
        > NFV Mano.<br>
        > The most interesting part if service provider management as part of the<br>
        > service catalog.<br>
<br>
<br>
        servicevm corresponds to (a part of) NFV orchestrator and VNF manager.<br>
        Especially life cycle management of VMs/services. configuration of services.<br>
        I think the above document and the NFV documents only give high level<br>
        statement of components, right?<br>
<br>
        thanks,<br>
<br>
<br>
        ><br>
        > Thanks,<br>
        > Dmitry<br>
        ><br>
        ><br>
        > On Wed, May 21, 2014 at 9:01 AM, Isaku Yamahata <<a href="mailto:isaku.yamahata@gmail.com">isaku.yamahata@gmail.com</a>>wrote:<br>
        ><br>
        > > Hi, I will also attend the NFV IRC meeting.<br>
        > ><br>
        > > thanks,<br>
        > > Isaku Yamahata<br>
        > ><br>
        > > On Tue, May 20, 2014 at 01:23:22PM -0700,<br>
        > > Stephen Wong <<a href="mailto:s3wong@midokura.com">s3wong@midokura.com</a>> wrote:<br>
        > ><br>
        > > > Hi,<br>
        > > ><br>
        > > >     I am part of the ServiceVM team and I will attend the NFV IRC<br>
        > > meetings.<br>
        > > ><br>
        > > > Thanks,<br>
        > > > - Stephen<br>
        > > ><br>
        > > ><br>
        > > > On Tue, May 20, 2014 at 8:59 AM, Chris Wright <<a href="mailto:chrisw@sous-sol.org">chrisw@sous-sol.org</a>><br>
        > > wrote:<br>
        > > ><br>
        > > > > * <a href="mailto:Balaji.P@freescale.com">Balaji.P@freescale.com</a> (<a href="mailto:Balaji.P@freescale.com">Balaji.P@freescale.com</a>) wrote:<br>
        > > > > > > -----Original Message-----<br>
        > > > > > > From: Kyle Mestery [mailto:<a href="mailto:mestery@noironetworks.com">mestery@noironetworks.com</a>]<br>
        > > > > > > Sent: Tuesday, May 20, 2014 12:19 AM<br>
        > > > > > > To: OpenStack Development Mailing List (not for usage questions)<br>
        > > > > > > Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design<br>
        > > summit<br>
        > > > > > ><br>
        > > > > > > On Mon, May 19, 2014 at 1:44 PM, Ian Wells <<a href="mailto:ijw.ubuntu@cack.org.uk">ijw.ubuntu@cack.org.uk</a><br>
        > > ><br>
        > > > > > > wrote:<br>
        > > > > > > > I think the Service VM discussion resolved itself in a way that<br>
        > > > > > > > reduces the problem to a form of NFV - there are standing issues<br>
        > > > > using<br>
        > > > > > > > VMs for services, orchestration is probably not a responsibility<br>
        > > that<br>
        > > > > > > > lies in Neutron, and as such the importance is in identifying the<br>
        > > > > > > > problems with the plumbing features of Neutron that cause<br>
        > > > > > > > implementation difficulties.  The end result will be that VMs<br>
        > > > > > > > implementing tenant services and implementing NFV should be much<br>
        > > the<br>
        > > > > > > > same, with the addition of offering a multitenant interface to<br>
        > > > > > > Openstack users on the tenant service VM case.<br>
        > > > > > > ><br>
        > > > > > > > Geoff Arnold is dealing with the collating of information from<br>
        > > people<br>
        > > > > > > > that have made the attempt to implement service VMs.  The problem<br>
        > > > > > > > areas should fall out of his effort.  I also suspect that the key<br>
        > > > > > > > points of NFV that cause problems (for instance, dealing with<br>
        > > VLANs<br>
        > > > > > > > and trunking) will actually appear quite high up the service VM<br>
        > > list<br>
        > > > > as<br>
        > > > > > > well.<br>
        > > > > > > > --<br>
        > > > > > > There is a weekly meeting for the Service VM project [1], I hope<br>
        > > some<br>
        > > > > > > representatives from the NFB sub-project can make it to this<br>
        > > meeting<br>
        > > > > and<br>
        > > > > > > participate there.<br>
        > > > > > [P Balaji-B37839] I agree with Kyle, so that we will have enough<br>
        > > synch<br>
        > > > > between Service VM and NFV goals.<br>
        > > > ><br>
        > > > > Makes good sense.  Will make sure to get someone there.<br>
        > > > ><br>
        > > > > thanks,<br>
        > > > > -chris<br>
        > > > ><br>
        > > > > _______________________________________________<br>
        > > > > OpenStack-dev mailing list<br>
        > > > > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
        > > > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
        > > > ><br>
        > ><br>
        > > > _______________________________________________<br>
        > > > OpenStack-dev mailing list<br>
        > > > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
        > > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
        > ><br>
        > ><br>
        > > --<br>
        > > Isaku Yamahata <<a href="mailto:isaku.yamahata@gmail.com">isaku.yamahata@gmail.com</a>><br>
        > ><br>
        > > _______________________________________________<br>
        > > OpenStack-dev mailing list<br>
        > > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
        > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
        > ><br>
<br>
        > _______________________________________________<br>
        > OpenStack-dev mailing list<br>
        > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
        > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
        --<br>
        Isaku Yamahata <<a href="mailto:isaku.yamahata@gmail.com">isaku.yamahata@gmail.com</a>><br>
<br>
        _______________________________________________<br>
        OpenStack-dev mailing list<br>
        <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
        <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
</blockquote></div><br></div></div>