Hello, Jessie,
About for the #3, I agree with Xu39s suggestion. I think Sapd, Vnffgd and
etc. should keep, and add the referenced classes in the model. And for the
papyrus diagram, there should add corresponding empty classes and their
associations.
Best Regards,
Chuyi.
----邮件原文----发件人：jessie jewitt
<[email protected]>收件人：onap-discuss
<[email protected]>,"郭楚怡" <[email protected]>抄 送: "yangxu (H)"
<[email protected]>,denglingli <[email protected]>,"zhang.maopeng1"
<[email protected]>,"zhan.jie1" <[email protected]>发送时间：2018-08-23
01:31:53主题：Re: [onap-discuss] [modeling] Network Service Descriptor modelHi
Chuyi- Yes, it39s my fault for not having reviewed this model when it was
originally proposed. What I would like to see for Casablanca is that we at
least "fix" it by doing the following:
1. Use a "pared down" version of the Papyrus NSD model that corresponds to what
was agreed, so we can output it from there on "clean", using the correct
associated class diagram.
2. Create the correct classes, and references to other classes and datatypes
that are already in the model (i.e. ConnectivityType is in our common model)
3. Suppress the references (and associations) that are not desired (meaning
there is no associated class in the model, i.e. Sapd, Vnffgd) You say they
haven39t been discussed yet, so I39m curious how the model was approved for R2?
If you prefer to keep these references, then we need to include the associated
classes that are referenced in the model.
4. I39m still not seeing a reference to VnfExtCp. Who is referencing that and
where?
I can prepare a new discussion wiki with what I39m proposing for next Monday39s
RM call. However, I would need an answer to #3 above. Do you want to remove the
references to classes that aren39t in your model, or do you want to add the
classes that are referenced. It would not be a good thing to reference them,
without defining them, which is currently the case in the model.
-Jessie
On Tue, Aug 21, 2018 at 10:38 PM, Chuyi Guo <[email protected]> wrote:
Hello, Jessie,
The Network Service model corresponds to the link is not only NSD, it
includes different classes, and has been discussed and voted in Service IM
call, I39m sorry you didn39t catch the call.
The current NS model is coordinated with the requirements of VF-C, not
simply copy the ETSI specifications. Since the scope of development plan for
C-release has been settled, other specific requirements should be proposed and
discussed in the later releases.
As for the issues you mentioned, I think you are right about the
NsVirtualLink, the type of VirtualLinkDesc is NsVirtualLinkDesc.
For 4 and 5, the details of Sapd, Vnffgd and etc., haven39t been discussed
yet, so is for VnfExtCp.
From my understanding, ConnectivityType should be in the NsVirtualLinkDesc,
which hasn39t been put in the papyrus class diagram , I think it is the point
where should update.
BR,
Chuyi.
----邮件原文----发件人：Jessie Jewitt <[email protected]>收件人："yangxu
(H)" <[email protected]>抄 送: "[email protected]"
<[email protected]>发送时间：2018-08-21 00:41:12主题：Re: [onap-discuss]
[modeling] Network Service Descriptor model
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
don39t 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
don39t 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. I39d 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 model. It was aligned with ETSI IFA014 v2.4.4.
Thanks,
Jessie
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12029): https://lists.onap.org/g/onap-discuss/message/12029
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]]
-=-=-=-=-=-=-=-=-=-=-=-
