[nemo-dev] The connectivity expression in NEMO
lifengkai at huawei.com
Fri Aug 14 01:35:51 UTC 2015
Just for my considerations. Welcome comments.
From: nemo-dev-bounces at lists.opendaylight.org [mailto:nemo-dev-bounces at lists.opendaylight.org] On Behalf Of Zhoutianran
Sent: Thursday, August 13, 2015 6:02 PM
To: Xiayinben; nemo-dev at lists.opendaylight.org
Subject: Re: [nemo-dev] The connectivity expression in NEMO
Please see inline.
Sent: Thursday, August 13, 2015 2:53 PM
To: Zhoutianran; nemo-dev at lists.opendaylight.org<mailto:nemo-dev at lists.opendaylight.org>
Subject: 答复: The connectivity expression in NEMO
I think it is different meaning for ‘connection’ in option 1 and option 2.
In option 1, the connection is connectivity. In option 2, the connection is resource between two nodes.
I think tenant’s intent of network have two level, one is resource intent, another is service intent.
[Fengkai] Then, I think here two types/roles of tenant are targeted, one concerns the resource management, while the other is aiming at the service requirements.
I prefer tenant express resource intent by connection, so the below topology describe the intent of tenant’s virtual network resource.
Connectivity is one type of service. I think in most of network, the connectivity between nodes is allowed, if we use ‘connection’ describe these connectivity, we need almost full mesh ‘connection’.
[Fengkai] The key here is the explicit definition or difference between “connection” and “connectivity”. If we agree that the connection is for resource and the connectivity is for the service types (or requirement, operation between the two specified nodes), then the tenant has his own choice to have a MESH connectivity or multiple P2P connectivity for the service requirements.
[TR.Z]Our connection model has the full mesh type. I do not think it’s hard to express. Otherwise, where to use the mesh type connection?
So I prefer connectivity is default service when there are connections/resource between nodes, if there are intermediate nodes between them, my assumption is these intermediate nodes have routing/forwarding capability.
If tenant want to express “A can not communicate with C”, they can use a policy express it:
Policy p1 Applyto nodeC action deny-list(nodeA)
[TR.Z]The harder part as I have mentioned before is that it’s difficult for the user to know node C has connectivity with A. And then to apply the policy.
[Fengkai] I agree with Tianran on this point. Moreover, the tenant should explicitly have a statement about the connectivity between A and C in case if he wants A to communicate with C, even the connection/resource (forwarding with the intermediate node B) already there.
And in most of scenario, tenant pay for connection resource rather than service, so I think we need an object to describe these resource intent.
[TR.Z]I do not think so. If user requires a service then he will be charged per service.
发件人: nemo-dev-bounces at lists.opendaylight.org<mailto:nemo-dev-bounces at lists.opendaylight.org> [mailto:nemo-dev-bounces at lists.opendaylight.org] 代表 Zhoutianran
发送时间: 2015年8月13日 11:51
收件人: nemo-dev at lists.opendaylight.org<mailto:nemo-dev at lists.opendaylight.org>
主题: [nemo-dev] The connectivity expression in NEMO
As I reviewed our model, I am thinking about this scenario.
I have the following user level topology, nodes are connected by connections:
[cid:image001.png at 01D0D672.B47F93E0]
There are two possible ways to interpret this as we have the same discussion on the IETF bar bof meeting.
1. One node can only communicate with nodes with explicit connection. E.g, A can communicate with B and D, but not C.
2. One node can communicate with all nodes with any connectivity. I.e, A can communicate with C since there is connectivity via B or D.
Personally, I support option 1. I think the “connection” should explicitly express the user’s intent for the connectivity. We cannot assume the intermediate nodes has the routing/forwarding capability.
However, option 2 will make the intent expression complex, and even worse have the user to know many details.
For example, with option 2, if the user only want A communicate with B and D. Then he has to know that C also has connectivity with A(this is hard). And he has to say “A cannot communicate with C”.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 10004 bytes
More information about the nemo-dev