Re: [clouds] draft-yokota-cloud-service-mobility

Hidetoshi Yokota <yokota@kddilabs.jp> Sat, 15 January 2011 22:17 UTC

Return-Path: <yokota@kddilabs.jp>
X-Original-To: clouds@core3.amsl.com
Delivered-To: clouds@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4E423A6B9B for <clouds@core3.amsl.com>; Sat, 15 Jan 2011 14:17:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BGrTjY5hyoy for <clouds@core3.amsl.com>; Sat, 15 Jan 2011 14:17:17 -0800 (PST)
Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by core3.amsl.com (Postfix) with ESMTP id BE4AA3A6C87 for <clouds@ietf.org>; Sat, 15 Jan 2011 14:17:16 -0800 (PST)
Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 5AC451748146; Sun, 16 Jan 2011 07:19:41 +0900 (JST)
X-Virus-Scanned: amavisd-new at kddilabs.jp
Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8TCuYrfa9iq; Sun, 16 Jan 2011 07:19:19 +0900 (JST)
Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 9DFD91748125; Sun, 16 Jan 2011 07:19:19 +0900 (JST)
Received: from [127.0.0.1] (unknown [10.8.0.6]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id B787F1B9B2; Sun, 16 Jan 2011 07:14:07 +0900 (JST)
Message-ID: <4D321D5F.4080200@kddilabs.jp>
Date: Sun, 16 Jan 2011 07:19:11 +0900
From: Hidetoshi Yokota <yokota@kddilabs.jp>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Vishwas Manral <vishwas.ietf@gmail.com>
References: <AANLkTimUgYk7FTi-F5kM_wfxmmG68ZCxKWHxKS_QR-Rk@mail.gmail.com> <4D2EE067.3010102@kddilabs.jp> <AANLkTikCFe=aO_7R=JtpU0E5hNQpi_ViUWGLaRU3oEuq@mail.gmail.com>
In-Reply-To: <AANLkTikCFe=aO_7R=JtpU0E5hNQpi_ViUWGLaRU3oEuq@mail.gmail.com>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Cc: clouds@ietf.org
Subject: Re: [clouds] draft-yokota-cloud-service-mobility
X-BeenThere: clouds@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Clouds pre-BOF discussion list <clouds.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/clouds>, <mailto:clouds-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/clouds>
List-Post: <mailto:clouds@ietf.org>
List-Help: <mailto:clouds-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clouds>, <mailto:clouds-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Jan 2011 22:17:18 -0000

Hi Vishwas,

Thanks for your clarifications. BTW, could you tell us about which
document we should read in PCE work? I think that the purpose and
requirements for service mobility in the cloud network could be
orthogonal and complimentary to those for PCE.

Regards,
-- 
Hidetoshi

(2011/01/14 2:25), Vishwas Manral wrote:
> Hi Hidetoshi-san,
> 
>>> 2. Scalability issues will occur if keepalives all go to the manager
>>> node. In my view there can be a heirarchy of keepalives.
>>
>> Are you suggesting an intermediate node that collects the keep-alives
>> from some group of managed nodes and sends an aggregated message to the
>> manager?
> Yes I am suggesting one such approach. You have to understand the
> number of resources that need to be monitored is very high.
> 
> A heirarchical approach will certainly help. Ofcourse there needs to
> be redundancy at each layer so that a failure in the intermediate does
> not lead to failures that may not necessarily be occuring.
> 
>>> 3. There should be a heirarchy of manager nodes too, considering the
>>> number of Execution nodes that need to be managed. So there should be
>>> a messaging exchange allowed between Manager and Manager node.
>>
>> I see. Either hierarchical structure (manager of managers) or
>> peer-to-peer structure (inter-manager) will be needed when the scale
>> becomes larger.
> That is correct. Like I mentioned I am trying to come to a PCE model.
> It is the same problem with different data. In PCE all the network
> nodes and interface properties are kept for Traffic Engineering
> purposes.
> https://datatracker.ietf.org/wg/pce/
> 
>>> 4. All TLV and headers should have length of 16 bits atleast. 8 bits
>>> is not scalable at all with the amount of information that is there.
>>
>> Good suggestion. Will expand the field length.
> This is extremely essential and we have seen issues in older protocols
> whih have used 8 bit length or type fields.
> 
>>> 5. There needs to be authentication in the packets to provide some security.
>>
>> Ok. Maybe, some option that can carry MAC (Message Authentication Code)
>> should be added. Or, do you think the whole message should be encrypted?
>> In that case, we should mandate IPSec connection between the Manager
>> Node and Execution Node.
> It is IPsec not IPSec. Yes we need to add a hash to the packet. If we
> are working over TCP we can use the TCP-AO or TCP-MD5 for the same.
> 
>>> 6. There needs to be async messaging allowed both from server to
>>> client and client to server.
>> Ok. I will add something like NOTIFY manage, which is spontaneous and
>> can
> Great!!!
> 
>>> 7. There is already a PCE framework that exists. We need to look at
>>> it. It is used for simialr purposes in a TE network.
>>
>> Could you tell me any reference document such as RFC or conference
>> paper, please?
> Sent the link above.
> 
> Thanks,
> Vishwas
> 
>> Regards,
>> --
>> Hidetoshi
>>
>>> Thanks,
>>> Vishwas
> 
> 
>