[openstack-dev] [Neutron][NFV] NFV BoF at design summit

Ogaki, Kenichi k.ogaki at gmail.com
Mon May 26 06:15:32 UTC 2014


Hi Isaku,

Thank you for your reply.

2014-05-26 13:47 GMT+09:00 Isaku Yamahata <isaku.yamahata at gmail.com>:

> On Fri, May 23, 2014 at 04:13:57PM +0900,
> "Ogaki, Kenichi" <k.ogaki at gmail.com> wrote:
>
> > Hi All,
>
> Hi.
>
> > I’m newbie to Openstack, so I want to clarify how OpenStack can implement
> > ETSI NFV Architecture.
> >
> > The concept of Advanced service looks like Network Service in ETSI NFV
> > Architecture as shown in Figure 3 below:
> > http://docbox.etsi.org/ISG/NFV/Open/Published/gs_NFV002v010101p.pdf
> >
> > As the functional role, VNF (Virtualized Network Function) may be
> > corespondent to Logical Service Instance.
> > 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.
> > 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.
> > In the same manner, Network Service is created from one or multiple
> VNF(s).
>
> Hmm, we don't use same terminology. Is there any public documentation for
> those terminology? The public docuemnts I can find is too high-level to
> understand the requirement.
>

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.

https://portal.etsi.org/tb.aspx?tbid=789&SubTB=789,795,796,801,800,798,799,797,802#lt-50612-drafts

DGS/NFV-MAN001, DGS/NFV-SWA001 should help you to understand the
architecture.



>
> The first target of servicevm project is to address the case of single
> service in single VM(VNFC in NFV terminology?) at first.
> Then evolve the implementation for more complex case with experiment.
>
>
I understand the current servicevm project is targeting an advanced service
composed of single VM.

Thanks,
Kenichi


> > My question is:
> > Is it possible that the current OpenStack components realize an advanced
> > service in the above manner?
> > Meaning, an advanced service is composed of hierarchical multiple VMs.
>
> I suspect no one knows. This is why we unite to make efforts for NFV.
>
>
> thanks,
> Isaku Yamahata
>
>
> > All the best,
> > Kenichi
> >
> >
> >
> > > From: Dmitry [mailto:meytin at gmail.com]
> > > Sent: Thursday, May 22, 2014 5:40 PM
> > > To: OpenStack Development Mailing List (not for usage questions)
> > > Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit
> > >
> > > Hi Isaku,
> > > Thank you for the updated link. I'n not sure where from I get the
> previous
> > > one, probably from the direct Google search.
> > > 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.
> > > In addition, it's possible that VNFC components will not be able to be
> > > placed on the same machine - anti-affinity rules.
> > > 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:
> > > 1) NFVO - which is using Nova to provision new Service VMs and Neutron
> to
> > > establish connectivity and service chaining
> > > 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?
> > > 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.
> > >
> > > This flow is more or less what was stated by NFV committee.
> > >
> > > Please let me know what you think about this and how far is that from
> what
> > > you planed for Service VM.
> > > In addition, I would happy to know if Service VM will be incubated for
> > > Juno release.
> > >
> > > Thank you very much,
> > > Dmitry
> > >
> > >
> > >
> > > On Thu, May 22, 2014 at 9:28 AM, Isaku Yamahata <
> isaku.yamahata at gmail.com>
> > > wrote:
> > >
> > >
> > >         On Wed, May 21, 2014 at 10:54:03AM +0300,
> > >         Dmitry <meytin at gmail.com> wrote:
> > >
> > >         > HI,
> > >
> > >         Hi.
> > >
> > >
> > >         > I would happy to get explanation of what is the difference
> > > between Adv
> > >
> > >         > Service Management<
> > > https://docs.google.com/file/d/0Bz-bErEEHJxLTGY4NUVvTzRDaEk/edit>from
> > >         > the Service VM
> > >
> > >         The above document is stale.
> > >         the right one is
> > >
> > >
> https://docs.google.com/document/d/1pwFVV8UavvQkBz92bT-BweBAiIZoMJP0NPAO4-60XFY/edit?pli=1
> > >
> > >
> https://docs.google.com/document/d/1ZWDDTjwhIUedyipkDztM0_nBYgfCEP9Q77hhn1ZduCA/edit?pli=1#
> > >         https://wiki.openstack.org/wiki/ServiceVM
> > >
> > >         Anyway how did you find the link? I'd like to remove stale
> links.
> > >
> > >
> > >         > and NFVO
> > >         > orchestration<
> > > http://www.ietf.org/proceedings/88/slides/slides-88-opsawg-6.pdf>from
> > >
> > >         > NFV Mano.
> > >         > The most interesting part if service provider management as
> part
> > > of the
> > >         > service catalog.
> > >
> > >
> > >         servicevm corresponds to (a part of) NFV orchestrator and VNF
> > > manager.
> > >         Especially life cycle management of VMs/services.
> configuration of
> > > services.
> > >         I think the above document and the NFV documents only give high
> > > level
> > >         statement of components, right?
> > >
> > >         thanks,
> > >
> > >
> > >         >
> > >         > Thanks,
> > >         > Dmitry
> > >         >
> > >         >
> > >         > On Wed, May 21, 2014 at 9:01 AM, Isaku Yamahata <
> > > isaku.yamahata at gmail.com>wrote:
> > >         >
> > >         > > Hi, I will also attend the NFV IRC meeting.
> > >         > >
> > >         > > thanks,
> > >         > > Isaku Yamahata
> > >         > >
> > >         > > On Tue, May 20, 2014 at 01:23:22PM -0700,
> > >         > > Stephen Wong <s3wong at midokura.com> wrote:
> > >         > >
> > >         > > > Hi,
> > >         > > >
> > >         > > >     I am part of the ServiceVM team and I will attend the
> > > NFV IRC
> > >         > > meetings.
> > >         > > >
> > >         > > > Thanks,
> > >         > > > - Stephen
> > >         > > >
> > >         > > >
> > >         > > > On Tue, May 20, 2014 at 8:59 AM, Chris Wright <
> > > chrisw at sous-sol.org>
> > >         > > wrote:
> > >         > > >
> > >         > > > > * Balaji.P at freescale.com (Balaji.P at freescale.com)
> wrote:
> > >         > > > > > > -----Original Message-----
> > >         > > > > > > From: Kyle Mestery [mailto:
> mestery at noironetworks.com]
> > >         > > > > > > Sent: Tuesday, May 20, 2014 12:19 AM
> > >         > > > > > > To: OpenStack Development Mailing List (not for
> usage
> > > questions)
> > >         > > > > > > Subject: Re: [openstack-dev] [Neutron][NFV] NFV
> BoF at
> > > design
> > >         > > summit
> > >         > > > > > >
> > >         > > > > > > On Mon, May 19, 2014 at 1:44 PM, Ian Wells <
> > > ijw.ubuntu at cack.org.uk
> > >         > > >
> > >         > > > > > > wrote:
> > >         > > > > > > > I think the Service VM discussion resolved
> itself in
> > > a way that
> > >         > > > > > > > reduces the problem to a form of NFV - there are
> > > standing issues
> > >         > > > > using
> > >         > > > > > > > VMs for services, orchestration is probably not a
> > > responsibility
> > >         > > that
> > >         > > > > > > > lies in Neutron, and as such the importance is in
> > > identifying the
> > >         > > > > > > > problems with the plumbing features of Neutron
> that
> > > cause
> > >         > > > > > > > implementation difficulties.  The end result
> will be
> > > that VMs
> > >         > > > > > > > implementing tenant services and implementing NFV
> > > should be much
> > >         > > the
> > >         > > > > > > > same, with the addition of offering a multitenant
> > > interface to
> > >         > > > > > > Openstack users on the tenant service VM case.
> > >         > > > > > > >
> > >         > > > > > > > Geoff Arnold is dealing with the collating of
> > > information from
> > >         > > people
> > >         > > > > > > > that have made the attempt to implement service
> VMs.
> > >  The problem
> > >         > > > > > > > areas should fall out of his effort.  I also
> suspect
> > > that the key
> > >         > > > > > > > points of NFV that cause problems (for instance,
> > > dealing with
> > >         > > VLANs
> > >         > > > > > > > and trunking) will actually appear quite high up
> the
> > > service VM
> > >         > > list
> > >         > > > > as
> > >         > > > > > > well.
> > >         > > > > > > > --
> > >         > > > > > > There is a weekly meeting for the Service VM
> project
> > > [1], I hope
> > >         > > some
> > >         > > > > > > representatives from the NFB sub-project can make
> it
> > > to this
> > >         > > meeting
> > >         > > > > and
> > >         > > > > > > participate there.
> > >         > > > > > [P Balaji-B37839] I agree with Kyle, so that we will
> > > have enough
> > >         > > synch
> > >         > > > > between Service VM and NFV goals.
> > >         > > > >
> > >         > > > > Makes good sense.  Will make sure to get someone there.
> > >         > > > >
> > >         > > > > thanks,
> > >         > > > > -chris
> > >         > > > >
> > >         > > > > _______________________________________________
> > >         > > > > OpenStack-dev mailing list
> > >         > > > > OpenStack-dev at lists.openstack.org
> > >         > > > >
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >         > > > >
> > >         > >
> > >         > > > _______________________________________________
> > >         > > > OpenStack-dev mailing list
> > >         > > > OpenStack-dev at lists.openstack.org
> > >         > > >
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >         > >
> > >         > >
> > >         > > --
> > >         > > Isaku Yamahata <isaku.yamahata at gmail.com>
> > >         > >
> > >         > > _______________________________________________
> > >         > > OpenStack-dev mailing list
> > >         > > OpenStack-dev at lists.openstack.org
> > >         > >
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >         > >
> > >
> > >         > _______________________________________________
> > >         > OpenStack-dev mailing list
> > >         > OpenStack-dev at lists.openstack.org
> > >         >
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > >
> > >         --
> > >         Isaku Yamahata <isaku.yamahata at gmail.com>
> > >
> > >         _______________________________________________
> > >         OpenStack-dev mailing list
> > >         OpenStack-dev at lists.openstack.org
> > >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > >
> > >
> > >
>
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> Isaku Yamahata <isaku.yamahata at gmail.com>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140526/20776a93/attachment.html>


More information about the OpenStack-dev mailing list