[openstack-dev] [Neutron][NFV] NFV BoF at design summit
Ogaki, Kenichi
k.ogaki at gmail.com
Fri May 23 07:13:57 UTC 2014
Hi All,
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).
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.
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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140523/1c10c893/attachment.html>
More information about the OpenStack-dev
mailing list