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

Hidetoshi Yokota <yokota@kddilabs.jp> Fri, 28 January 2011 08:22 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 06B843A6B9E for <clouds@core3.amsl.com>; Fri, 28 Jan 2011 00:22:59 -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=[AWL=0.000, 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 Lr2jOGaBwTjQ for <clouds@core3.amsl.com>; Fri, 28 Jan 2011 00:22:57 -0800 (PST)
Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by core3.amsl.com (Postfix) with ESMTP id 22F473A6B98 for <clouds@ietf.org>; Fri, 28 Jan 2011 00:22:56 -0800 (PST)
Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id C007B174826D; Fri, 28 Jan 2011 17:26:00 +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 VSKtKLaHX-yb; Fri, 28 Jan 2011 17:26:00 +0900 (JST)
Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 5FF981748242; Fri, 28 Jan 2011 17:26:00 +0900 (JST)
Received: from [127.0.0.1] (yokotaiMac.mn.mip.kddilabs.jp [172.19.90.26]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 938F11B85F; Fri, 28 Jan 2011 17:25:52 +0900 (JST)
Message-ID: <4D427D8B.4070505@kddilabs.jp>
Date: Fri, 28 Jan 2011 17:25:47 +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> <AANLkTikn5ixzODCnLSDa=5jh7Mc91MH2=VAJu1iFJaDT@mail.gmail.com> <4D3EE86B.5050008@kddilabs.jp> <AANLkTimY3ab7b6+bsg00GOhcQKz-ZWukJLMk+BXf6Xen@mail.gmail.com>
In-Reply-To: <AANLkTimY3ab7b6+bsg00GOhcQKz-ZWukJLMk+BXf6Xen@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: Fri, 28 Jan 2011 08:22:59 -0000

Hi Vishwas,

(2011/01/26 3:05), Vishwas Manral wrote:
> Hi Yokota-san,
> 
> For most of the things I mention without too much context, there is
> probably an IETF WG for it. :))
> https://datatracker.ietf.org/wg/nea/charter/ is the link. It is simlar
> to the Microsoft NAP protocol or the TNC protocol.

Thanks for the link. I remembered what it was.

> The protocol the PA and PB, are similar. The point there is when a new
> resource joins it is authenticated and current state checked, based on
> its current state it is allowed to join the network.

I see. The protocol checks if the posture of the joined system meets the
requirements for the network compliance policy. I also think that
security consideration is important and it has useful information
regarding the attributes to convey, but it does not basically handle
mobility of the functions or sessions, right?

Regards,
-- 
Hidetoshi


> Thanks,
> Vishwas
> 
> 2011/1/25 Hidetoshi Yokota<yokota@kddilabs.jp>jp>:
>> Hi Vishwas,
>>
>> Thanks for your information. Are there any reference documents?
>>
>> Regards,
>> --
>> Hidetoshi
>>
>> (2011/01/25 3:39), Vishwas Manral wrote:
>>> Hi Yokota-san,
>>>
>>> Another thing I was thinking about was actually aligning the work with
>>> NEA work (which has a few similar requirements).
>>>
>>> Thanks,
>>> Vishwas
>>>
>>> 2011/1/13 Hidetoshi Yokota<yokota@kddilabs.jp>jp>:
>>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
> 
> 
>