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

[Hidetoshi Yokota <[e-mail]>]

Hi Vishwas,

(2011/01/26 3:05), Vishwas Manral wrote:
> 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.

Thanks for the link. I remembered what it was.

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

I see. The protocol checks if the posture of the joined system meets the
requirements for the network compliance policy. I also think that
security consideration is important and it has useful information
regarding the attributes to convey, but it does not basically handle
mobility of the functions or sessions, right?

Regards,
-- 
Hidetoshi


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