Re: [Nfvrg] Call for adoption of draft-natarajan-nfvrg-containers-for-nfv

[Roberto Riggio <[e-mail]>]

Hi,

actually we are bumping into this aspect continuously while working on NFV
and
in particular on MEC scenario. Essentially, echoing what Feynman said in
relation
to nanotechnology, it seems that there "is plenty of space at the bottom"
of the
NFV domain.

In particular we had several doubts regarding whatever it makes sense to use
an openstack+an ETSI mano framework to orchestrate edge workloads where
you have low footprint whiteboxes. Also in some cases the VNF that you end
up
orchestrating and pretty different from your regular VNF. E.g. they could
be part
of a portion of a RAT stack running as a VNF (see the small cell forum work
on
functional split).

What we are doing is to develop a VIM+MANO framework that could orchestrate
containers and clickOS instances. At the moment we have only basic
orchestration
for clickOS based VNFs (with support for stateful migration). Significant
work is
to be done in order to address also the most popular container
technologies. The
click OS orchestrator is already available on github.

Given the scope of this document what is really interesting to me is to
understand
what would be the KPIs to be considered in order to motivate such a
lightMANO
(virtualization/orchestration overhead? baseline resources requirement just
to bootstrap
the system? ...)

R.




On Mon, Jan 9, 2017 at 4:02 PM, Ram Krishnan <[e-mail]> wrote:

> Hi Roberto,
>
> I echo Diego's thoughts. Would certainly be interested in knowing more.
>
> ​Thanks,
> Ramki​
>
> On Mon, Jan 9, 2017 at 12:33 AM, Diego R. Lopez <
> [e-mail]> wrote:
>
>> Hi Roberto,
>>
>> I would be very much interested in knowing more about this approach. At
>> the last OpenStack Summit in Barcelona I had the opportunity to discuss the
>> approach of a lightweight VIM (or even a general lightweight cloud
>> orchestration) for use cases like the one that you mention. We believe the
>> current OpenVIM inside OpenMANO is a clear example of it.
>>
>> Be goode,
>>
>> On 7 Jan 2017, at 11:52 , Roberto Riggio <[e-mail]> wrote:
>>
>> I was thinking about frameworks like dockyard. There are many other tools
>> (more or less complex)
>> to manage containers without going to full blown VIMs like openstack.
>> However what is missing is
>> a Lightweight MANO to replace platforms like OPNFV etc. il the low-end
>> side of the spectrum. We
>> are actually working on this but it is still very far from a public
>> release.
>>
>> R.
>>
>> On Fri, Jan 6, 2017 at 10:23 PM, ram krishnan <[e-mail]>
>> wrote:
>>
>>> Hi Roberto,
>>>
>>>
>>>
>>> Valid point. Do you have any specific examples in mind?
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Ramki
>>>
>>>
>>>
>>> *From:* Roberto Riggio [mailto:[e-mail]]
>>> *Sent:* Friday, January 6, 2017 12:59 PM
>>> *To:* ram krishnan <[e-mail]>
>>> *Cc:* Azhar Sayeed <[e-mail]>; Diego R. Lopez <
>>> [e-mail]>; [e-mail]
>>>
>>> *Subject:* Re: [Nfvrg] Call for adoption of
>>> draft-natarajan-nfvrg-containers-for-nfv
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> I was wondering if the lightweight NFV performance comparison should
>>> also be extended
>>>
>>> to the rest of the stack. For example openstack + opnfv could be very
>>> heavyweight while
>>>
>>> other management platforms for containers (if they exists) could be
>>> executed on low
>>>
>>> power platforms (which could make sense in some deployments).
>>>
>>>
>>>
>>> R.
>>>
>>>
>>>
>>> On Fri, Jan 6, 2017 at 9:47 PM, ram krishnan <[e-mail]>
>>> wrote:
>>>
>>> Hi Azhar,
>>>
>>>
>>>
>>> Thanks for the comments and the interest. The rationale behind adoption
>>> is we see strong community interest in the topic and have reasonable
>>> content in the document. We still have more steps like last call before the
>>> RFC publication and are expecting good community contribution to the
>>> document prior to that.
>>>
>>>
>>>
>>> For the performance comparisons, we didn't use HW acceleration
>>> techniques since they are application and deployment specific; for example,
>>> a small CPE in an enterprise branch may never use any hardware acceleration
>>> because of the low throughput requirements. Any specific suggestions
>>> including references in this area are most welcome.
>>>
>>>
>>>
>>> Container networking is definitely an interesting topic. We will
>>> certainly capture the challenges in a mixed Container/OpenStack
>>> environment, how efforts like Kuryr are attempting to address these and how
>>> SR-IOV plays out in this scenario. Any other suggestions are welcome.
>>>
>>>
>>>
>>> Can you please elaborate more on the single threading support?
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Ramki
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Nfvrg [mailto:[e-mail]] On Behalf Of Azhar Sayeed
>>> Sent: Friday, January 6, 2017 8:11 AM
>>> To: Diego R. Lopez <[e-mail]>
>>> Cc: [e-mail]
>>> Subject: Re: [Nfvrg] Call for adoption of draft-natarajan-nfvrg-containe
>>> rs-for-nfv
>>>
>>>
>>>
>>> Hi Diego and Authors..
>>>
>>>
>>>
>>> Can you clarify if any data path acceleration techniques were used to
>>> measure throughput between guest and host OS. If not what is the usefulness
>>> of that metric - If the idea is to show raw comparisons then fine - if the
>>> idea is to show how bad the VMs are when compared to Unikernel and
>>> containers then you have achieved it it well..
>>>
>>>
>>>
>>> The main issues with Unikernels or containers for NFV are not discussed
>>> in depth - Issues such as single threading support, IP address assignment
>>> and container networking need further exploration and study. Need at least
>>> statements in the document that those are for further study.
>>>
>>>
>>>
>>> So perhaps I am missing the point of adoption of this draft - may be the
>>> objectives can be clarified.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Azhar
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> > On Jan 3, 2017, at 7:14 PM, Diego R. Lopez <
>>> [e-mail]> wrote:
>>>
>>> >
>>>
>>> > Hi,
>>>
>>> >
>>>
>>> > This first message of the new year is to launch a two-week adoption
>>> call for draft-natarajan-nfvrg-containers-for-nfv. Ramki and I believe
>>> the document is mature enough to consider its adoption, once it has evolved
>>> from an analysis of container technology into a more comprehensive
>>> discussion of lightweight technologies in NFV.
>>>
>>> >
>>>
>>> > Please indicate in your comments “support” or “no support” and discuss
>>> how this draft will contribute to the goals of NFVRG.
>>>
>>> >
>>>
>>> > The current draft is available at:
>>>
>>> >
>>>
>>> > https://datatracker.ietf.org/doc/draft-natarajan-nfvrg-conta
>>> iners-for-nfv/
>>>
>>> >
>>>
>>> > Be goode,
>>>
>>> >
>>>
>>> >
>>>
>>> > --
>>>
>>> > "Esta vez no fallaremos, Doctor Infierno"
>>>
>>> >
>>>
>>> > Dr Diego R. Lopez
>>>
>>> > Telefonica I+D
>>>
>>> > http://people.tid.es/diego.lopez/
>>>
>>> >
>>>
>>> > e-mail: [e-mail]
>>>
>>> > Tel:    [phone] <+34%20913%2012%2090%2041>
>>>
>>> > Mobile: [phone] <+34%20682%2005%2010%2091>
>>>
>>> > ----------------------------------
>>>
>>> >
>>>
>>> > _______________________________________________
>>>
>>> > Nfvrg mailing list
>>>
>>> > [e-mail]
>>>
>>> > https://www.irtf.org/mailman/listinfo/nfvrg
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> Nfvrg mailing list
>>>
>>> [e-mail]
>>>
>>> https://www.irtf.org/mailman/listinfo/nfvrg
>>>
>>>
>>> _______________________________________________
>>> Nfvrg mailing list
>>> [e-mail]
>>> https://www.irtf.org/mailman/listinfo/nfvrg
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> --------------------------------------------------------
>>>
>>> Roberto Riggio, Ph.D.
>>>
>>> CREATE-NET
>>>
>>> Chief Scientist
>>>
>>> Future Networks (FuN)
>>>
>>> Via alla Cascata 56/D - 38123 Povo Trento (Italy)
>>>
>>> e-mail: [e-mail] <- NEW EMAIL ADDRESS
>>>
>>> office: ([phone]
>>>
>>> Fax: [phone]
>>>
>>> mobile: [phone]
>>>
>>> skype: hamvil
>>>
>>> homepage: http://www.robertoriggio.net/
>>>
>>> --------------------------------------------------------
>>>
>>
>>
>>
>> --
>> --------------------------------------------------------
>> Roberto Riggio, Ph.D.
>> CREATE-NET
>> Chief Scientist
>> Future Networks (FuN)
>> Via alla Cascata 56/D - 38123 Povo Trento (Italy)
>> e-mail: [e-mail] <- NEW EMAIL ADDRESS
>> office: ([phone]
>> Fax: [phone]
>> mobile: [phone]
>> skype: hamvil
>> homepage: http://www.robertoriggio.net/
>> --------------------------------------------------------
>>
>>
>> --
>> "Esta vez no fallaremos, Doctor Infierno"
>>
>> Dr Diego R. Lopez
>> Telefonica I+D
>> http://people.tid.es/diego.lopez/
>>
>> e-mail: [e-mail]
>> Tel:    [phone] <+34%20913%2012%2090%2041>
>> Mobile: [phone] <+34%20682%2005%2010%2091>
>> ----------------------------------
>>
>>
>
>
> --
> Thanks,
> Ramki
>



-- 
--------------------------------------------------------
Roberto Riggio, Ph.D.
CREATE-NET
Chief Scientist
Future Networks (FuN)
Via alla Cascata 56/D - 38123 Povo Trento (Italy)
e-mail: [e-mail] <- NEW EMAIL ADDRESS
office: ([phone]
Fax: [phone]
mobile: [phone]
skype: hamvil
homepage: http://www.robertoriggio.net/
--------------------------------------------------------