Re: [vnfpool] Follow-up question from the BOF

DIEGO LOPEZ GARCIA <> Thu, 24 July 2014 14:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 026161A035B for <>; Thu, 24 Jul 2014 07:06:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BpzjW8NurnKS for <>; Thu, 24 Jul 2014 07:06:09 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3E7001A0350 for <>; Thu, 24 Jul 2014 07:06:02 -0700 (PDT)
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 8ACEC88138; Thu, 24 Jul 2014 16:05:59 +0200 (CEST)
Received: from (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 695D08813B; Thu, 24 Jul 2014 16:05:59 +0200 (CEST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 24 Jul 2014 16:05:58 +0200
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.990.7; Thu, 24 Jul 2014 14:05:57 +0000
Received: from ([]) by ([]) with mapi id 15.00.0990.007; Thu, 24 Jul 2014 14:05:57 +0000
To: "Y. Richard Yang" <>
Thread-Topic: [vnfpool] Follow-up question from the BOF
Thread-Index: AQHPpemjVlcpgUSIKESa236wz9XhvZusnakAgAJx2oCAAAQyAIAACp2AgAAmoQA=
Date: Thu, 24 Jul 2014 14:05:57 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 028256169F
x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(252514010)(199002)(24454002)(51704005)(377454003)(110136001)(92726001)(2656002)(19617315012)(31966008)(83716003)(46102001)(81542001)(2171001)(20776003)(4396001)(74662001)(106116001)(92566001)(74502001)(87936001)(15202345003)(15975445006)(82746002)(76482001)(85852003)(21056001)(95666004)(66066001)(105586002)(77982001)(19580405001)(561944003)(99396002)(83072002)(64706001)(81342001)(93886003)(86362001)(101416001)(33656002)(36756003)(16236675004)(107046002)(83322001)(50986999)(19580395003)(106356001)(85306003)(80022001)(79102001)(54356999)(76176999)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR06MB251;; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en;
Content-Type: multipart/alternative; boundary="_000_0850FF9399BD4206AB0B86021BBEF960telefonicacom_"
MIME-Version: 1.0
Cc: "" <>, Michael Tuexen <>, "" <>
Subject: Re: [vnfpool] Follow-up question from the BOF
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for virtual network function resource pooling." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Jul 2014 14:06:22 -0000


As one of the supporters of the idea of not leaving state management out of scope, I am glad to see Richard's proposal and happy to support the idea of exploring a solution able to encompass vendor specific approaches.

Be goode,

On 24 Jul 2014, at 07:47 , Y. Richard Yang <<>> wrote:

Martin, Michael,

IPR concerns are valid, but if they are crucial to solve the problem, and the solution provides higher benefit, they could be addressed, right?

Regarding vendor specific solution, this is a very good point! Please take a look at approaches such as merge/split. They allow vendor specific packaging of NF state. Hence, transfers of state can be only among NFs of the same vendor. The advance, however, is that at least the controller can be different from the NF vendors. This is a good progress, in my view. Make sense?


On Jul 24, 2014 7:09 AM, "Michael Tuexen" <<>> wrote:

On 24 Jul 2014, at 06:54, Martin Stiemerling <<>> wrote:

> Hi Richard,
> Am 22.07.14 um 17:34 schrieb Y. Richard Yang:
>> Hi Martin,
>> Here is one point. One constraint of the proposed work, in my view, is
>> that the scope does not consider state management. Most useful NFs are
>> stateful. Hence, removing state management from the scope is not ideal,
>> and hence is a limit. There is interesting recent progress in generic,
>> reusable NF state management, such as Merge/Split
>> (
>> If this is included, I believe that the group can develop a lot more
>> more solutions.
> state management is an interesting topic, but there has been explicit community feedback during the first bof that this is not something the potential wg should be working on, as this is very vendor specific.
... and there are most likely a lot IPRs... That was one of the reasons
state sharing was excluded from the scope of RSerPool...

Best regards
>  Martin
> _______________________________________________
> vnfpool mailing list

vnfpool mailing list<>

"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D

Tel:    +34 913 129 041
Mobile: +34 682 051 091


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição