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

Hidetoshi Yokota <yokota@kddilabs.jp> Thu, 13 January 2011 11:20 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 9E12A3A6B75 for <clouds@core3.amsl.com>; Thu, 13 Jan 2011 03:20:20 -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 8cGf2dhGohJm for <clouds@core3.amsl.com>; Thu, 13 Jan 2011 03:20:19 -0800 (PST)
Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by core3.amsl.com (Postfix) with ESMTP id 40C3C3A6B60 for <clouds@ietf.org>; Thu, 13 Jan 2011 03:20:18 -0800 (PST)
Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id C30EF174821A; Thu, 13 Jan 2011 20:22:29 +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 fyBoZRW87uip; Thu, 13 Jan 2011 20:22:29 +0900 (JST)
Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 7FDF11748219; Thu, 13 Jan 2011 20:22:29 +0900 (JST)
Received: from [127.0.0.1] (t-chiba-PC.mn.mip.kddilabs.jp [172.19.90.26]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 0B8F61B9B2; Thu, 13 Jan 2011 20:17:19 +0900 (JST)
Message-ID: <4D2EE067.3010102@kddilabs.jp>
Date: Thu, 13 Jan 2011 20:22:15 +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>
In-Reply-To: <AANLkTimUgYk7FTi-F5kM_wfxmmG68ZCxKWHxKS_QR-Rk@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: Thu, 13 Jan 2011 11:20:20 -0000

Hi Vishwas,

Thanks a lot for your input. The current draft is the initial cut, so
there should be many to add ;-). Please also see inline:

(2011/01/12 10:26), Vishwas Manral wrote:
> Hi,
> 
> I looked at the document and there are a few very basic things I
> wanted to state that need to be added:
> 
> 1. There needs to be a capability exchange from the Execution node to
> the Manager node.

Yes, that should be done at the registration phase. I should add it with
an appropriate option format.

> 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?

> 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.

> 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.

> 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.

> 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 be sent by either side at any time.

> 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?

Regards,
-- 
Hidetoshi

> Thanks,
> Vishwas
> 
> 
>