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

Hidetoshi Yokota <yokota@kddilabs.jp> Thu, 13 January 2011 11:28 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 06D7528B23E for <clouds@core3.amsl.com>; Thu, 13 Jan 2011 03:28:51 -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 Kj0NB6ItS5Q1 for <clouds@core3.amsl.com>; Thu, 13 Jan 2011 03:28:49 -0800 (PST)
Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by core3.amsl.com (Postfix) with ESMTP id 541963A6B72 for <clouds@ietf.org>; Thu, 13 Jan 2011 03:28:45 -0800 (PST)
Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id C738C1748219; Thu, 13 Jan 2011 20:31:06 +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 7H32hlTJzIEj; Thu, 13 Jan 2011 20:31:06 +0900 (JST)
Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 8ADAC1748218; Thu, 13 Jan 2011 20:31:06 +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 EC2DD1B9B2; Thu, 13 Jan 2011 20:25:55 +0900 (JST)
Message-ID: <4D2EE26C.9060604@kddilabs.jp>
Date: Thu, 13 Jan 2011 20:30:52 +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> <AANLkTikau03aemQbaA_wFNZ5wS5NUNzhzqzGsKdTrbBF@mail.gmail.com>
In-Reply-To: <AANLkTikau03aemQbaA_wFNZ5wS5NUNzhzqzGsKdTrbBF@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:28:51 -0000

Hi Vishwas,

Thanks again for your good input.

(2011/01/12 11:17), Vishwas Manral wrote:
> Hi,
> 
> Some other things I can think of are NACK's and retransmission of
> messages when no message is received.
> 
> Also I assume the protocol will probably work over TCP. A prot number
> needs to be defined for the same.

We haven't decided the transport protocol, yet. If it is TCP or SCTP,
then the retransmission procedure can be left to them, which I think
would be simpler than employing UDP. NACK-like message is definitely
needed when, for example, the requested operation cannot be performed.
Maybe, we should define the status code in the ACK message to convey
more detailed information. Port number is also definitely needed and
this I-D will request IANA to assign a specific one at a later stage.

Regards,
-- 
Hidetoshi

> Thanks,
> Vishwas
> 
> On Tue, Jan 11, 2011 at 5:26 PM, Vishwas Manral<vishwas.ietf@gmail.com>  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.
>> 2. Scalability issues will occur if keepalives all go to the manager
>> node. In my view there can be a heirarchy of keepalives.
>> 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.
>> 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.
>> 5. There needs to be authentication in the packets to provide some security.
>> 6. There needs to be async messaging allowed both from server to
>> client and client to server.
>> 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.
>>
>> Thanks,
>> Vishwas
>>
> 
> 
>