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

[Hidetoshi Yokota <[e-mail]>]

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<[e-mail]>:
>> 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
>>>
>>>
>>>
>>
>>
>>
> 
> 
>