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

[Vishwas Manral <[e-mail]>]

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.

Thanks,
Vishwas

2011/1/15 Hidetoshi Yokota <[e-mail]>:
> 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.
>> https://datatracker.ietf.org/wg/pce/
>>
>>>> 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
>>
>>
>>
>
>