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

From: Vishwas Manral <[email-masked]>
Date: Tue, 11 Jan 2011 17:26:00 -0800

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.
2. Scalability issues will occur if keepalives all go to the manager
node. In my view there can be a heirarchy of keepalives.
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.
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.
5. There needs to be authentication in the packets to provide some security.
6. There needs to be async messaging allowed both from server to
client and client to server.
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.

Thanks,
Vishwas

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 11 Jan 2011 18:17:40 -0800

Hi,

Some other things I can think of are NACK's and retransmission of
messages when no message is received.

Also I assume the protocol will probably work over TCP. A prot number
needs to be defined for the same.

Thanks,
Vishwas

---

From: Hidetoshi Yokota <[email-masked]>
Date: Thu, 13 Jan 2011 20:22:15 +0900

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:

> 1. There needs to be a capability exchange from the Execution node to

Yes, that should be done at the registration phase. I should add it with
an appropriate option format.

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

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

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

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

> 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

---

From: Hidetoshi Yokota <[email-masked]>
Date: Thu, 13 Jan 2011 20:30:52 +0900

Hi Vishwas,

Thanks again for your good input.

> needs to be defined for the same.

We haven't decided the transport protocol, yet. If it is TCP or SCTP,
then the retransmission procedure can be left to them, which I think
would be simpler than employing UDP. NACK-like message is definitely
needed when, for example, the requested operation cannot be performed.
Maybe, we should define the status code in the ACK message to convey
more detailed information. Port number is also definitely needed and
this I-D will request IANA to assign a specific one at a later stage.

Regards,
-- 
Hidetoshi

> Thanks,
> Vishwas
> 
> On Tue, Jan 11, 2011 at 5:26 PM, Vishwas Manral<[email-masked]>  wrote:
>> Hi,
>>

---

From: Vishwas Manral <[email-masked]>
Date: Thu, 13 Jan 2011 09:26:15 -0800

Hi Hidetoshi-san,

I would think TCP is a good option for this. PCE uses TCP too.

Thanks,
Vishwas

---

From: Vishwas Manral <[email-masked]>
Date: Thu, 13 Jan 2011 09:25:31 -0800

Hi Hidetoshi-san,

> from some group of managed nodes and sends an aggregated message to the
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.

> peer-to-peer structure (inter-manager) will be needed when the scale
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/

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

> In that case, we should mandate IPSec connection between the Manager
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.

> can
Great!!!

> Could you tell me any reference document such as RFC or conference
Sent the link above.

Thanks,
Vishwas

---

From: Hidetoshi Yokota <[email-masked]>
Date: Sun, 16 Jan 2011 07:19:11 +0900

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

---

From: Vishwas Manral <[email-masked]>
Date: Sun, 16 Jan 2011 11:43:43 -0800

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

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 24 Jan 2011 10:39:59 -0800

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

---

From: Hidetoshi Yokota <[email-masked]>
Date: Wed, 26 Jan 2011 00:12:43 +0900

Hi Vishwas,

Thanks for your information. Are there any reference documents?

Regards,
-- 
Hidetoshi

(2011/01/25 3:39), Vishwas Manral wrote:
> 2011/1/13 Hidetoshi Yokota<[email-masked]>:
>> Hi Vishwas,
>>

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 25 Jan 2011 10:05:59 -0800

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

---

From: Hidetoshi Yokota <[email-masked]>
Date: Fri, 28 Jan 2011 17:25:47 +0900

Hi Vishwas,

> to the Microsoft NAP protocol or the TNC protocol.

Thanks for the link. I remembered what it was.

> 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<[email-masked]>:
>> Hi Vishwas,
>>