I have updated the Network Service Descriptor <https://wiki.onap.org/display/DW/Network+Service+Descriptor+Model+-+Based+on+R2>model on the wiki based on recommendations from this team to align with R2. Two notes: 1. NSD was missing in R2 a nsdIdentifier. This is a must have. 2. Some of the types are empty. I'll fill those in next week.
-Jessie On Thu, Aug 23, 2018 at 9:40 AM, Jessie Jewitt < [email protected]> wrote: > Hi Xu- > Two comments: > 1. I will mark association member ends and referenced classes as > experimental and put them in the output. > 2. You don't see things like ConnectivityType on the diagram because it is > a class diagram and ConnectivityType is a datatype. > > -Jessie > > On Wed, Aug 22, 2018 at 7:31 PM, Xu Yang <[email protected]> wrote: > >> Hi Jessie, >> >> >> >> Please see inline. >> >> >> >> Best regards, >> >> Xu >> >> >> >> *From:* [email protected] [mailto:[email protected]] *On >> Behalf Of *Jessie Jewitt >> *Sent:* Thursday, August 23, 2018 1:44 AM >> *To:* yangxu (H) <[email protected]> >> *Cc:* 郭楚怡 <[email protected]>; onap-discuss < >> [email protected]>; denglingli <[email protected]>; >> zhang.maopeng1 <[email protected]>; zhan.jie1 < >> [email protected]> >> *Subject:* Re: [onap-discuss] [modeling] Network Service Descriptor model >> >> >> >> Hi Xu- >> >> I hadn't seen your response when I answered Chuyi's email. Please see >> my comments embedded below... >> >> Thanks, >> >> Jessie >> >> >> >> On Wed, Aug 22, 2018 at 12:50 AM, yangxu (H) <[email protected]> wrote: >> >> Hi Jessie, >> >> >> >> In R2, we did have a call for approval for the NSD model, as shown in >> https://lists.onap.org/g/onap-discuss/message/8829. Let’s not argue on >> that anymore and focus on improving the current model. >> >> Jessie: Yes, agree >> >> >> >> It’s true that we don’t have a UML diagram for the NSD model on the wiki >> page I give, the proposal from my side is that we create a Papyrus model >> for the NSD (as we are doing it now) and align it with the R2 wiki page, >> fix issues and put it into R3 clean model. >> >> Jessie: Agree. That's what I proposed to Chuyi. I'll align the current >> NSD model in Papyrus with the R2 model, but fix the issues and prepare this >> to go in clean. I can have it ready by next Monday, hopefully, though I >> won't be on the call. >> >> Further improvement and alignment with ETSI specs are better to be put >> into R4 as we are coming to the deadline for the final draft. >> >> Jessie: Agree. >> >> Regarding the issues, I think you are right the current model is not >> complete, we can either remove those attributes that are not defined or >> mark them as experimental like what we have done for the VNFD model. >> >> Jessie: The "attributes" that are not defined are member ends of >> associations. We need to either remove the associations, or add the >> referenced classes in the model. I personally don't think it would be >> correct to mark them as "experimental" as they would be incomplete >> definitions. For example, you reference a Sapd, but don't define the Sapd >> class? It wouldn't be possible to implement something like that. >> >> [xy] I agree, I’m suggesting either we remove those >> attributes/associations or add the referenced classes and mark those >> classes as “experimental”. For example, either we don’t have any >> attributes/classes called Sapd in the model, or we add an empty Sapd class >> marked as “experimental”. The reason why I’m suggesting to mark the class >> as “experimental” is that we don’t have a discussion on those classes >> before (and not likely to have before the deadline), marking them as >> “experimental” shows further discussion and refinement are needed. >> >> >> >> And as Chuyi pointed out, there’s something on the wiki that are not >> shown in the Papyrus model, update is needed to keep them aligned. >> >> >> >> Jessie: I didn't catch what was on the wiki, but not in the model. Can >> you remind me what that is? >> >> [xy] For example, I think several attributes (testAccess, >> connectivityType, etc.) of the NsVirtualLinkDesc class are not shown in the >> diagram. >> >> Best regards, >> >> Xu >> >> >> >> *From:* 郭楚怡 [mailto:[email protected]] >> *Sent:* Wednesday, August 22, 2018 1:38 PM >> *To:* jessie.jewitt <[email protected]> >> *Cc:* onap-discuss <[email protected]>; yangxu (H) < >> [email protected]>; denglingli <[email protected]>; >> zhang.maopeng1 <[email protected]>; zhan.jie1 < >> [email protected]> >> *Subject:* Re:Re: [onap-discuss] [modeling] Network Service Descriptor >> model >> >> >> >> >> >> >> >> 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, I'm sorry you didn't 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., haven't been >> discussed yet, so is for VnfExtCp. >> >> From my understanding, ConnectivityType should be in the >> NsVirtualLinkDesc, which hasn't 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 >> 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 (#12046): https://lists.onap.org/g/onap-discuss/message/12046 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]] -=-=-=-=-=-=-=-=-=-=-=-
