Hi Xu-
The link you refer to in your email to Network Service (which I assume
is Descriptor) is not a model that is acceptable to me. I certainly don't
remember voting on this in R2. Here are some of the reasons I personally
cannot accept it:
1. There is no class diagram showing the relationships between entities, so
I don't really know what concepts you are trying to model.
2. The relationship that should exist is between NSD and VirtualLinkDesc,
and not NsVirtualLink. The attribute in NSD called virtualLinkDesc (which
should be the endpoint of the association) is of type string. That is
incorrect.
3. I believe you mean NsVirtualLink to VirtualLinkDesc, as the first
attribute is virtualLinkDescId.
4. Many of the attributes in NSD refer to types that are not defined in the
model (Sapd, Vnffgd, NsDf...)
5. Same comment above regarding NsVirtualLink. It contains types that are
not in your model, like SecurityParameters
6. ConnectivityType, as a datatype, has been moved to our Common model,
which we will need to define as part of our final resource IM in clean, and
not a NSD model. The benefit of putting datatypes like these in "Common" is
that we define them once, and then reference them from multiple models,
like Resource (where NSD lives) and VNF.
7. There is nothing in the model that refers to a VnfExtCp and its
relationship to NSD.
These are just some of the issues.
I believe a better approach is to take the NSD model defined that is based
on ETSI (that addresses the above issues) and pare it down to something
equivalent, if you want. I'd be happy to update the NSD model to show what
it would look like.
-Jessie
On Mon, Aug 20, 2018 at 7:35 AM, yangxu (H) <[email protected]> wrote:
> Hi All,
>
>
>
> Thank you for joining today’s resource IM call and having the meaningful
> discussion.
>
> My apologize for not allocating much time reviewing the NSD model, as M3
> is approaching, I think we need to trigger offline discussion to help
> accelerate the progress.
>
>
>
> The main issue I see for the NSD model is the scope for R3 documentation.
> The current proposal from Jessie is based on IFA014 spec, while the model
> agreed in R2 (https://wiki.onap.org/display/DW/NetworkService) is only
> subset of the spec. And whether we need to include PNFD model as part of
> the NSD model (like ETSI does), and how we document the PNFD model in R3
> remains a question.
>
>
>
> My suggestion is we keep aligned with the previous agreement and
> implementation in R3. Which means we only document the trimmed NSD in R3
> and try to capture the PNFD model which would be implemented by the SDC
> team.
>
>
>
> Please share your opinions on this issue and let’s try to finalize the
> clean model before the deadline, thanks.
>
>
>
> Best regards,
>
> Xu
>
>
>
> *From:* [email protected] [mailto:[email protected]] *On
> Behalf Of *Jessie Jewitt
> *Sent:* Tuesday, August 7, 2018 3:09 AM
> *To:* onap-discuss <[email protected]>
> *Subject:* [onap-discuss] [modeling] Network Service Descriptor model
>
>
>
> Please review and provide comments by 8/13 (on the wiki) for the proposed
> Network
> Service Descriptor
> <https://wiki.onap.org/display/DW/Proposed+Network+Service+Descriptor+Model>
> model. It was aligned with ETSI IFA014 v2.4.4.
>
>
>
> Thanks,
>
> Jessie
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11952): https://lists.onap.org/g/onap-discuss/message/11952
Mute This Topic: https://lists.onap.org/mt/24212025/21656
Group Owner: [email protected]
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
