<div dir="ltr">Hi Isaku,<br><div class="gmail_extra"><br>Thank you for your reply.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">2014-05-26 13:47 GMT+09:00 Isaku Yamahata <span dir="ltr"><<a href="mailto:isaku.yamahata@gmail.com" target="_blank">isaku.yamahata@gmail.com</a>></span>:<br>
<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">On Fri, May 23, 2014 at 04:13:57PM +0900,<br>
"Ogaki, Kenichi" <<a href="mailto:k.ogaki@gmail.com">k.ogaki@gmail.com</a>> wrote:<br>
<br>
> Hi All,<br>
<br>
Hi.<br>
<div class=""><br>
> I’m newbie to Openstack, so I want to clarify how OpenStack can implement<br>
> ETSI NFV Architecture.<br>
><br>
> The concept of Advanced service looks like Network Service in ETSI NFV<br>
> Architecture as shown in Figure 3 below:<br>
> <a href="http://docbox.etsi.org/ISG/NFV/Open/Published/gs_NFV002v010101p.pdf" target="_blank">http://docbox.etsi.org/ISG/NFV/Open/Published/gs_NFV002v010101p.pdf</a><br>
><br>
> As the functional role, VNF (Virtualized Network Function) may be<br>
> corespondent to Logical Service Instance.<br>
> However, in ETSI NFV Architecture, VNF is composed of VNFC (VNF Component)<br>
> or VDU (Virtual Deployment Unit) and each VNFC or VDU instance is deployed<br>
> as a VM.<br>
> These VNFC or VDU instances are connected by logical or physical network<br>
> links in a manner of a kind of service chaining, then a VNF instance is<br>
> created.<br>
> In the same manner, Network Service is created from one or multiple VNF(s).<br>
<br>
</div>Hmm, we don't use same terminology. Is there any public documentation for<br>
those terminology? The public docuemnts I can find is too high-level to<br>
understand the requirement.<br></blockquote><div><br></div><div>Most of documents haven’t been publicized yet, But, if your affiliation is a member or participant of ETSI NFV ISG, you can get the final or stable working group drafts below.</div>
<div><br></div><div><a href="https://portal.etsi.org/tb.aspx?tbid=789&SubTB=789,795,796,801,800,798,799,797,802#lt-50612-drafts">https://portal.etsi.org/tb.aspx?tbid=789&SubTB=789,795,796,801,800,798,799,797,802#lt-50612-drafts</a></div>
<div><br></div><div>DGS/NFV-MAN001, DGS/NFV-SWA001 should help you to understand the architecture.</div><div><br></div><div> </div><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>
The first target of servicevm project is to address the case of single<br>
service in single VM(VNFC in NFV terminology?) at first.<br>
Then evolve the implementation for more complex case with experiment.<br>
<div class=""><br></div></blockquote><div><br></div><div>I understand the current servicevm project is targeting an advanced service composed of single VM. <br></div><div> </div><div>Thanks,</div><div>Kenichi</div><div><br>
</div><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"><div class="">
<br>
> My question is:<br>
> Is it possible that the current OpenStack components realize an advanced<br>
> service in the above manner?<br>
> Meaning, an advanced service is composed of hierarchical multiple VMs.<br>
<br>
</div>I suspect no one knows. This is why we unite to make efforts for NFV.<br>
<br>
<br>
thanks,<br>
Isaku Yamahata<br>
<div class=""><div class="h5"><br>
<br>
> All the best,<br>
> Kenichi<br>
><br>
><br>
><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<br>
> > one, probably from the direct Google search.<br>
> > If we're talking about NFV Mano, it's very important to keep NFVO and VNFM<br>
> > as a separate services, where VNFM might be (and probably will be) supplied<br>
> > jointly with a vendor's specific VNF.<br>
> > In addition, it's possible that VNFC components will not be able to be<br>
> > placed on the same machine - anti-affinity rules.<br>
> > Talking in NFV terminology, we need to have a new OpenStack Services which<br>
> > (from what I've understood from the document you sent) is called Adv<br>
> > Service and is responsible to be:<br>
> > 1) NFVO - which is using Nova to provision new Service VMs and Neutron to<br>
> > establish connectivity and service chaining<br>
> > 2) Service Catalog - to accommodate multiple VNF services. Question: the<br>
> > same problem exists with Trove which need a catalog for multiple concrete<br>
> > 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<br>
> > decide where Service VM should be placed and which LSI should be<br>
> > 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<br>
> > you planed for Service VM.<br>
> > In addition, I would happy to know if Service VM will be incubated for<br>
> > 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>><br>
> > 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<br>
> > between Adv<br>
> ><br>
> >         > Service Management<<br>
> > <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>
> ><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>

> ><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<<br>
> > <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<br>
> > of the<br>
> >         > service catalog.<br>
> ><br>
> ><br>
> >         servicevm corresponds to (a part of) NFV orchestrator and VNF<br>
> > manager.<br>
> >         Especially life cycle management of VMs/services. configuration of<br>
> > services.<br>
> >         I think the above document and the NFV documents only give high<br>
> > 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 <<br>
> > <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<br>
> > NFV IRC<br>
> >         > > meetings.<br>
> >         > > ><br>
> >         > > > Thanks,<br>
> >         > > > - Stephen<br>
> >         > > ><br>
> >         > > ><br>
> >         > > > On Tue, May 20, 2014 at 8:59 AM, Chris Wright <<br>
> > <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<br>
> > questions)<br>
> >         > > > > > > Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at<br>
> > design<br>
> >         > > summit<br>
> >         > > > > > ><br>
> >         > > > > > > On Mon, May 19, 2014 at 1:44 PM, Ian Wells <<br>
> > <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<br>
> > a way that<br>
> >         > > > > > > > reduces the problem to a form of NFV - there are<br>
> > standing issues<br>
> >         > > > > using<br>
> >         > > > > > > > VMs for services, orchestration is probably not a<br>
> > responsibility<br>
> >         > > that<br>
> >         > > > > > > > lies in Neutron, and as such the importance is in<br>
> > identifying the<br>
> >         > > > > > > > problems with the plumbing features of Neutron that<br>
> > cause<br>
> >         > > > > > > > implementation difficulties.  The end result will be<br>
> > that VMs<br>
> >         > > > > > > > implementing tenant services and implementing NFV<br>
> > should be much<br>
> >         > > the<br>
> >         > > > > > > > same, with the addition of offering a multitenant<br>
> > interface to<br>
> >         > > > > > > Openstack users on the tenant service VM case.<br>
> >         > > > > > > ><br>
> >         > > > > > > > Geoff Arnold is dealing with the collating of<br>
> > information from<br>
> >         > > people<br>
> >         > > > > > > > that have made the attempt to implement service VMs.<br>
> >  The problem<br>
> >         > > > > > > > areas should fall out of his effort.  I also suspect<br>
> > that the key<br>
> >         > > > > > > > points of NFV that cause problems (for instance,<br>
> > dealing with<br>
> >         > > VLANs<br>
> >         > > > > > > > and trunking) will actually appear quite high up the<br>
> > service VM<br>
> >         > > list<br>
> >         > > > > as<br>
> >         > > > > > > well.<br>
> >         > > > > > > > --<br>
> >         > > > > > > There is a weekly meeting for the Service VM project<br>
> > [1], I hope<br>
> >         > > some<br>
> >         > > > > > > representatives from the NFB sub-project can make it<br>
> > to this<br>
> >         > > meeting<br>
> >         > > > > and<br>
> >         > > > > > > participate there.<br>
> >         > > > > > [P Balaji-B37839] I agree with Kyle, so that we will<br>
> > 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>
> >         > > > ><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>
> >         > > ><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>
> >         > ><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>
> >         ><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>
> ><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>
</div></div></blockquote></div><br></div></div>