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

Vishwas Manral <> Sun, 16 January 2011 19:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F11353A6E04 for <>; Sun, 16 Jan 2011 11:54:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.434
X-Spam-Status: No, score=-3.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RHcX0e2+4aCO for <>; Sun, 16 Jan 2011 11:54:00 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 808853A6D2A for <>; Sun, 16 Jan 2011 11:53:58 -0800 (PST)
Received: by wyf23 with SMTP id 23so4710462wyf.31 for <>; Sun, 16 Jan 2011 11:56:27 -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=CotLFucq8EMXGJYiWy2X3xDrEHK4bcD42Fql/uKlLAQ=; b=BTvxbVjUweFBYoqCfjKGv64NqgMvfXLIhbRFKxI9peFEchFifs1aBz2KORbDMjD8Ag AElxt28jTa4wpatBxAoXyiGILE27rXs6gvjoQ+bsk722oFtVzDcoidNezRxH9S3qfXRH 3vYPGyDamA5X7SHQhQwBETuBHtvXJhiMMvJD4=
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=LnwXU0Rxud9FzDsWrrlDd5JKu/3FNyV52XRZq52EkbyN/nG6w5DgPQ7niOqb5skzXO Da4ir3FEPI1M17nioa55tj9CPYEo4EdvsQZD/CsYIrRid1uAesQqeQf+CPcdg3DEmm+X UjVccZJkU0Sle5ACOscjuoF5bFD2tmz0UjvAg=
MIME-Version: 1.0
Received: by with SMTP id t62mr2462831wel.60.1295207024030; Sun, 16 Jan 2011 11:43:44 -0800 (PST)
Received: by with HTTP; Sun, 16 Jan 2011 11:43:43 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Sun, 16 Jan 2011 11:43:43 -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: Sun, 16 Jan 2011 19:54:01 -0000

Hi Hidetoshi-san,

I know the two are complementery.

Though the content of the messages may be different, the architecture
and messaging can be similar. Though they are not exactly the same the
PCE server keeps track of TE resources in the router and on request
from the clients assigns resources.

I am saying we can use the architecture and protocol mechanisms
wherever relevent.


2011/1/15 Hidetoshi Yokota <>jp>:
> 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.
>>>> 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