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

[Vishwas Manral <[e-mail]>]

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.

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.

Thanks,
Vishwas

2011/1/25 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
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>