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

Balaji.P at freescale.com Balaji.P at freescale.com
Mon May 26 06:44:30 UTC 2014


Hi Kenichi and Isaku,

Thanks for bringing this to discussion.

IMHO, NFV ETSI drafts are still evolving and it is good that we should keep track of these drafts so that NFV and Service VM teams will align to these drafts for NFV deployments.

Also, NFV ETSI drafts has robust architecture, which we have to infuse it in Service VM architecture for aligning with NFV ETSI drafts and discussions.

Any comments/suggestions appreciated.

Regards,
Balaji.P 

> -----Original Message-----
> From: Isaku Yamahata [mailto:isaku.yamahata at gmail.com]
> Sent: Monday, May 26, 2014 10:17 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: isaku.yamahata at gmail.com
> Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit
> 
> 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.
> 
> 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.
> 
> 
> > 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-BweBAiIZoMJP0
> > > NPAO4-60XFY/edit?pli=1
> > >
> > >
> https://docs.google.com/document/d/1ZWDDTjwhIUedyipkDztM0_nBYgfCEP9Q77hhn
> 1ZduCA/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>fro
> > > m
> > >
> > >         > 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



More information about the OpenStack-dev mailing list