[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] Groups - draft-tosca-nfv-v1.0-wd01-rev02 uploaded
|
Hi Shitao,
Based on the discussion in today’s NFV meeting, I have a number of questions about the document:
1.
Section 5.1 in the document shows a service template example. It obviously includes the various VNFs and VLs, but it also shows two connection points
(CP01 and CP02). Two questions:
a.
Is there a need to model the “service endpoints” explicitly? Couldn’t service endpoints be modeled implicitly instead using capabilities exposed by
the Virtual Links? Any Virtual Link capability that isn’t already used in a relationship should be usable “externally”?
b.
If we agree there is a need to model “service endpoint” explicitly, I recommend that we introduce a new Node Type (e.g. ServiceEndpoint) specifically
for that purpose (rather than using ConnectionPoint), for the following reasons:
i. ConnectPoint has a “binding” requirement for a Linkable capability. Using ConnectionPoint
to model service endpoints would result in “dangling” binding requirements that cannot be satisfied by the orchestrator.
ii. ConnectionPoint is a concept that is intended to be used for VDUs, not for VNFs. We don’t
expose ConnectionPoint at the VNF level anywhere else. If we use ConnectionPoint to model service endpoints, I believe we’re mixing different levels of abstraction.
2.
The VL (virtual link) node type has a “connectivity_type” property that specifies whether the VL is an E-Line, an E-LAN, or an E-Tree. I propose that
instead we introduce three different VL node types, one for each of the three virtual links to be modeled.
3.
The VL node type has a “connections” property that lists the attached connection points. A couple of comments about this:
a.
As I stated above, I believe that we should use the ConnectionPoint node type only for VDUs, not for VNFs. ConnectionPoints model connectivity details
that are not necessary at the level of abstraction of VNFs. If we agree with this, then we should avoid referencing ConnectionPoints in Virtual Links
b.
That said, we need a mechanism to specify how the various VNFs are connected to the various VLs. In Tosca, the proper way to do this is using relationships
that associated requirements with capabilities. VNFs use a “virtual_link” requirement that needs to get associated with a “virtual_linkable” capability in the VL. The VL node type needs to get extended with the “virtual_linkable” capability
c.
VL node types also have a “number_of_endpoints” property that specifies how many endpoints can connect to this VL. I believe this is better modeled
in the context of the “virtual_linkable” capability using an “occurrences” keyword. We already have such a keyword on requirement definitions. I propose that we also introduce this keyword on capability definitions in order to specify how many times a requirement
can be satisfied by this capability.
4.
In all the examples, we’ve used “tosca.nodes.nfv”, “tosca.capabilities.nfv”, etc. to indicate the name space for NFV-related types. To simplify things,
how about using “nfv” as the root name for the nfv name space. This would allow us to use “nvf.nodes”, “nfv.capabilities”, “nfv.relationships”, etc.? Thanks, Chris From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
On Behalf Of shitao li
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]