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

Vishwas Manral <> Thu, 13 January 2011 17:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C186728C10E for <>; Thu, 13 Jan 2011 09:26:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.47
X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JoO6KSJk4aSH for <>; Thu, 13 Jan 2011 09:26:39 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 380C328C0F9 for <>; Thu, 13 Jan 2011 09:26:39 -0800 (PST)
Received: by wyf23 with SMTP id 23so2013937wyf.31 for <>; Thu, 13 Jan 2011 09:28:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cAG+HaLto5LuzbEGdH+WpzXE8SPmub8LU3TybO9xfkA=; b=olM7HYqQR4tKYsSI0oA1hA0RxcPKYhqdt5OTMN3CH3yUuSaE4dztnMW2DlvR7nfbla aghyFPRHBab01M2dt1GTxSoqU/cqtmaWHh0EtyenA1LRGzej5clcgIEkr+loKSgKwK6D 1WBO89sWblyUG1qvxrAmDQiIQcwVueuzsBu3g=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=T9BO8fja1cxEHcfCLVNamBDh4Socn7GELS0DJmM3CXslBVA+ht16KYaLx9fNYXoykd P0Rg5Vsjl0Gm1QSLK3Ay+rMaYYMKOgyQCUlqKbKcyjWwwcLjvUQ3IPEAn0u08JVIYs4s gVZV+gJavLj/vzz9d+xOsaXZp0osF5pVPfp6s=
MIME-Version: 1.0
Received: by with SMTP id j55mr800880wek.90.1294939531580; Thu, 13 Jan 2011 09:25:31 -0800 (PST)
Received: by with HTTP; Thu, 13 Jan 2011 09:25:31 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Thu, 13 Jan 2011 09:25:31 -0800
Message-ID: <>
From: Vishwas Manral <>
To: Hidetoshi Yokota <>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [clouds] draft-yokota-cloud-service-mobility
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Clouds pre-BOF discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Jan 2011 17:26:41 -0000

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

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

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


> Regards,
> --
> Hidetoshi
>> Thanks,
>> Vishwas