from:"John Strassner"

Re: [onap-discuss] [modeling] ONAP Modeling Guidelines

2018-04-05 Thread John Strassner

Joel Halpern of Ericsson is leading the project. I think that suggestions
should go to him directly.

In the meantime, when we get a chance, some of the members of the IM
Guidelines group will post to ONAP some of the more serious problems with
the existing IISOMI guidelines. This is why we are reworking the guidelines
in the first place.


On Thu, Apr 5, 2018 at 11:05 AM, jessie jewitt <
jessie.jew...@oamtechnologies.com> wrote:

> If you have any questions or comments regarding MEF's use of modeling
> guidelines, or modeling techniques, please let me know and I will
> communicate your request to the MEF committee chairs and the CTO.
> -Jessie
>
> On Wed, Apr 4, 2018 at 3:15 PM, John Strassner <straz...@gmail.com> wrote:
>
>> Actually, the MEF is NOT using these guidelines anymore, mainly due to
>> the errors with respect to UML interpretation and the restrictions placed
>> on what UML artifacts can be used in a model.
>>
>> On Wed, Apr 4, 2018 at 2:50 PM, jessie jewitt <
>> jessie.jew...@oamtechnologies.com> wrote:
>>
>>> You are correct that it is not an "industry standard" like an IEEE spec.
>>> It is an informal agreement by industry players to use the same UML
>>> Modeling Guidelines. The ONF, ETSI, and MEF use these guidelines, even
>>> though you personally may choose not to do so.
>>>
>>>
>>> On Wed, Apr 4, 2018 at 1:42 PM, John Strassner <straz...@gmail.com>
>>> wrote:
>>>
>>>> I'm sorry, but IISOMI is NOT an "industry standard". It is an "informal
>>>> agreement" that has some consensus among some parts of the industry.
>>>>
>>>> In fact, it contains a number of incorrect conclusions about what UML
>>>> is and is not, and greatly limits the power of using UML constructs.
>>>>
>>>> John
>>>>
>>>> On Wed, Apr 4, 2018 at 12:07 PM, jessie jewitt <
>>>> jessie.jew...@oamtechnologies.com> wrote:
>>>>
>>>>> Hello Hui and Lingli-
>>>>>  I've noticed that the modeling guidelines defined here:
>>>>> https://wiki.onap.org/pages/viewpage.action?pageId=16003072
>>>>>
>>>>> do not specify that we should be following the industry defined UML
>>>>> Modeling Guidelines (IISOMI 514) and Papyrus Guidelines (IISOMI 515)
>>>>> defined here:
>>>>> https://wiki.onap.org/pages/viewpage.action?pageId=20874416
>>>>>
>>>>> As a result, there are ONAP IM models being developed that are not in
>>>>> conformance with industry standard guidelines. (For example, some of the
>>>>> Service IM class attributes do not conform to using lower camel case).
>>>>>
>>>>> If these IISOMI Guidelines have not been "accepted" as ONAP
>>>>> Guidelines, I'd like to propose an agenda item to discuss this at the next
>>>>> modeling subcommittee meeting.
>>>>>
>>>>> Thank you,
>>>>> Jessie
>>>>>
>>>>> ___
>>>>> onap-discuss mailing list
>>>>> onap-discuss@lists.onap.org
>>>>> https://lists.onap.org/mailman/listinfo/onap-discuss
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> regards,
>>>> John
>>>>
>>>
>>>
>>
>>
>> --
>> regards,
>> John
>>
>
>


-- 
regards,
John
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [modeling] Papyrus version

2018-01-12 Thread John Strassner

???
I thought the latest release of Papyrus is 3.1.0, which I am running with
Oxygen 2.
Could you be more specific?

regards,
John

On Fri, Jan 12, 2018 at 7:54 AM, Davis, Nigel  wrote:

> Hi,
>
>
>
> I propose we use 3.2.0 RC4 which is the latest stable release and then we
> stick with that (until we find features in a new version of Papyrus that we
> need).  I will need to do a small update to the video to provide
> instructions on how to load that. That will take me a couple of days. I
> have the original video in a number of chapters. It may be worth me
> providing those as that will mean that people can home in on the relevant
> one without having to wade through the whole video to try to find the
> relevant part. We can discuss this off line.
>
>
>
> I will aim to get ONF, MEF etc to settle on 3.2.0 RC4 as well (although
> clearly I may not be able to achieve this).
>
>
>
> Nigel
>
>
>
> *From:* denghui (L) [mailto:denghu...@huawei.com]
> *Sent:* 10 January 2018 19:25
> *To:* Davis, Nigel ; am8...@att.com
> *Cc:* onap-discuss@lists.onap.org
> *Subject:* [**EXTERNAL**] [modeling] Papyrus version
>
>
>
> Hi Nigel
>
>
>
> Could you kindly help to advice what’s final version for papyrus for
> modeling team? Thanks a lot for your kind help.
>
>
>
> Hi Andy,
>
>
>
> Have you recorded Nigel’s training about Papyrus last Friday? Thanks a lot
> for your kind help
>
>
>
> Best regards,
>
>
>
> DENG Hui
>
> ___
> onap-discuss mailing list
> onap-discuss@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-discuss
>
>


-- 
regards,
John
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [modeling] ONAP modeling workshop program

2017-12-14 Thread John Strassner

I agree on clear use of Terminology. That is why I said in my presentation
that in the MEF Core Model, we define a MEFNetworkFunction to differentiate
it from an ETSI NFV network function. That being said, let's look at the
definition of Network Function from ETSI GS NFV 003 v1.2.1:

*Network Function (NF): *functional block within a network
infrastructure that has well-defined external interfaces and well-defined
functional behavior

I assert that this actually supports the definition that I gave. The
problem is that many people do not have a control theory background. If you
do, then you will realize that a functional block is actually exactly what
I described:  a black box that, given a set of inputs and a state, uses a
transfer function to produce a set of outputs. The transfer function is key
to providing well-defined functional behavior.

Nevertheless, we called this MEFNetworkFunction because the ETSI definition
did not explicitly say the above.

regards,
John

On Thu, Dec 14, 2017 at 10:00 AM, Michael Brenner <mich...@gigaspaces.com>
wrote:

> All,
>
> My 2 cents. It really is becoming imperative to agree on ONAP terminology.
> During today's CIM WS presentation from John Strassner, it became obvious
> that how we define the ONAP information model is dependent on terminology.
> We can have 10 different IMs and all of them may be right in the context of
> their terminology, but completely wrong when we use terminology from
> somewhere else. The term "network function" was the best example.
> We could iterate for a very long time on IM if we do not first agree on
> the ONAP terminology - and a term cannot be all things, especially if we
> want to reconcile ONAP IM with other IMs.
>
> Regards,
> Michael
>
> On Thu, Dec 14, 2017 at 12:22 PM, denghui (L) <denghu...@huawei.com>
> wrote:
>
>> Hello all
>>
>>
>>
>> There is a small change to let Kevin present first about IM then let SDO
>> to discuss it later.
>>
>> https://wiki.onap.org/display/DW/ONAP+Modeling+Workshop+Program
>>
>>
>>
>> Thanks a lot
>>
>>
>>
>> DENG Hui
>>
>> ___
>> onap-discuss mailing list
>> onap-discuss@lists.onap.org
>> https://lists.onap.org/mailman/listinfo/onap-discuss
>>
>>
>
>
> --
> Michael Brenner, Chief Architect NFV
> --
> M: +1-732-895-5772 http://getcloudify.org
> <http://getcloudify.org?utm_source=signaturesatori_medium=email_campaign=Cloudify%204.0%20Webinar>
> @cloudifysource
> <https://twitter.com/CloudifySource>
> <https://www.linkedin.com/company-beta/17918192/>
> <https://github.com/cloudify-cosmo>
> <https://www.youtube.com/cloudifysource>
>
> <http://getcloudify.org/webinars/the-new-cloudify-4.html?utm_source=signaturesatori_medium=email_campaign=Cloudify%204.0%20Webinar>
>
>
> ___
> onap-discuss mailing list
> onap-discuss@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-discuss
>
>


-- 
regards,
John
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Questions on the ONAP R2+ Resource IM

2017-11-22 Thread John Strassner

Happy to. Although please realize that there is NO instance of a composite
pattern in "ONAP Service 2017-11-08" The same is true for "ONAP Resource
2017-11-08". Hence, I would like to know what diagram you are looking at...

...In fact, there are a LOT of recursive relationships, and in general,
these cause problems in modeling. If that is unclear, please let me know.

regards,
John

On Wed, Nov 22, 2017 at 5:47 PM, Lingli Deng <denglin...@chinamobile.com>
wrote:

> I am not sure we are looking at the same picture.
>
> Let us have more discussion offline.
>
>
>
> Thanks,
>
> Lingli
>
>
>
> *From:* John Strassner [mailto:straz...@gmail.com]
> *Sent:* 2017年11月23日 9:43
> *To:* 邓灵莉 <denglin...@chinamobile.com>; John Strassner <straz...@gmail.com
> >
> *Cc:* MAYER, ANDREW J <am8...@att.com>; SCAGGS, KEVIN <ks0...@att.com>;
> onap-discuss@lists.onap.org; WECHSLER, CHESLA C <cw1...@att.com>
> *Subject:* Re: [onap-discuss] Questions on the ONAP R2+ Resource IM
>
>
>
> Sorry, forgot one other thing. Looking at the Service diagram (11-08
> version), you are NOT using the composite pattern. What you have is a
> recursive aggregation, which is NOT the same thing, and is prone to causing
> modeling problems if you have subclasses of ServiceComponentDesc.
>
>
>
> If you need help on patterns, please let me know, and we can chat offline.
>
>
>
> regards,
>
> John
>
>
>
> On Wed, Nov 22, 2017 at 5:38 PM, John Strassner <straz...@gmail.com>
> wrote:
>
> There are a number of reasons, but the most important are:
>
>
>
>1) The Decorator enables attributes and/or methods to be used to
> construct a new object dynamically at runtime; the composite is fixed at
> design time
>
>2) The Decorator enables one to use all or part of an object to build a
> new object. The composite, like the ONF spec pattern and the TMF spec
> pattern, is restricted to using the entire object.
>
>
>
>
>
> regards,
>
> John
>
>
>
> On Wed, Nov 22, 2017 at 3:44 PM, 邓灵莉 <denglin...@chinamobile.com> wrote:
>
> I believe we are using the composite pattern currently.
> Why the decorator pattern would be better?
>
> Lingli
>
>
>
>
>
> 发自网易邮箱大师
>
> On 11/23/2017 05:03, John Strassner <straz...@gmail.com> wrote:
>
> While I agree with the requirements that Andy said (e.g., a
> ServiceComponent should support multiple Services, and a ServiceComponent
> should exist independent of a Service),
>
>
>
>1) this is assuming that a ServiceComponent is as defined in the MEF
>
>2) I don't think the existing model works - you either need a composite
> pattern or a decorator pattern to do this correctly
>
>
>
> Of the two, I believe that a decorator pattern is better suited (that's
> how we modeled this in the MEF).
>
>
>
> regards,
>
> John
>
>
>
> On Wed, Nov 22, 2017 at 11:15 AM, MAYER, ANDREW J <am8...@att.com> wrote:
>
> Xu,
>
>
>
> Thank you for the questions. I provided a partial answer in-line with your
> questions.
>
>
>
> Best Regards,
> Andy
>
>
>
> *Andy Mayer, Ph.D. *| PMTS, D2.0 Integration | AT Labs | Phone: +1
> (732) 420-9945 <(732)%20420-9945> | am8...@att.com
>
>
>
> *From:* yangxu (H) [mailto:yang...@huawei.com]
> *Sent:* Thursday, November 16, 2017 10:29 AM
> *To:* MAYER, ANDREW J <am8...@att.com>; FORSYTH, JAMES <jf2...@att.com>;
> SCAGGS, KEVIN <ks0...@att.com>
> *Cc:* onap-discuss@lists.onap.org
> *Subject:* [onap-discuss] Questions on the ONAP R2+ Resource IM
>
>
>
> Dear Jimmy, Andy and Kevin
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_-7Eks0567=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=3UIWLh7P2rAFm1qdZ7jMYQ=DbssT-o1dpLv7XFdBf9mssaQbsxlSnlqaWzswYhP6ws=ZB3dq-yjpATtQpVg2ouQJGL7G0nAaG5DV3y5DUSS2F4=>
> ,
>
> As discussed in the modeling call, there’re several questions regarding
> the resource IM that need to be answered. Please find them below:
>
>To Andy & Kevin,
>
> 1)Regarding the design time model (the figure shows the relationship
> between ServiceDesc, ServiceComponentDesc, ResourceCatalogItem, VNFDesc and
> VNFCDesc), the AID document states that "a service component has a zero to
> many relationship to service while the vnf component has is related to
> exactly one vnf". What's the case for a service component to have zero
> relationship to service? Does it imply that a service component can exist
> alone (without being involved in a service) in design time?
>
> [AJM] Service Component Descriptors may exist independently from t

Re: [onap-discuss] Questions on the ONAP R2+ Resource IM

2017-11-22 Thread John Strassner

Sorry, forgot one other thing. Looking at the Service diagram (11-08
version), you are NOT using the composite pattern. What you have is a
recursive aggregation, which is NOT the same thing, and is prone to causing
modeling problems if you have subclasses of ServiceComponentDesc.

If you need help on patterns, please let me know, and we can chat offline.

regards,
John

On Wed, Nov 22, 2017 at 5:38 PM, John Strassner <straz...@gmail.com> wrote:

> There are a number of reasons, but the most important are:
>
>1) The Decorator enables attributes and/or methods to be used to
> construct a new object dynamically at runtime; the composite is fixed at
> design time
>2) The Decorator enables one to use all or part of an object to build a
> new object. The composite, like the ONF spec pattern and the TMF spec
> pattern, is restricted to using the entire object.
>
>
> regards,
> John
>
> On Wed, Nov 22, 2017 at 3:44 PM, 邓灵莉 <denglin...@chinamobile.com> wrote:
>
>> I believe we are using the composite pattern currently.
>> Why the decorator pattern would be better?
>>
>> Lingli
>>
>>
>> 发自网易邮箱大师
>> On 11/23/2017 05:03, John Strassner <straz...@gmail.com> wrote:
>>
>> While I agree with the requirements that Andy said (e.g., a
>> ServiceComponent should support multiple Services, and a ServiceComponent
>> should exist independent of a Service),
>>
>>1) this is assuming that a ServiceComponent is as defined in the MEF
>>2) I don't think the existing model works - you either need a
>> composite pattern or a decorator pattern to do this correctly
>>
>> Of the two, I believe that a decorator pattern is better suited (that's
>> how we modeled this in the MEF).
>>
>> regards,
>> John
>>
>> On Wed, Nov 22, 2017 at 11:15 AM, MAYER, ANDREW J <am8...@att.com> wrote:
>>
>>> Xu,
>>>
>>>
>>>
>>> Thank you for the questions. I provided a partial answer in-line with
>>> your questions.
>>>
>>>
>>>
>>> Best Regards,
>>> Andy
>>>
>>>
>>>
>>> *Andy Mayer, Ph.D. *| PMTS, D2.0 Integration | AT Labs | Phone: +1
>>> (732) 420-9945 <(732)%20420-9945> | am8...@att.com
>>>
>>>
>>>
>>> *From:* yangxu (H) [mailto:yang...@huawei.com]
>>> *Sent:* Thursday, November 16, 2017 10:29 AM
>>> *To:* MAYER, ANDREW J <am8...@att.com>; FORSYTH, JAMES <jf2...@att.com>;
>>> SCAGGS, KEVIN <ks0...@att.com>
>>> *Cc:* onap-discuss@lists.onap.org
>>> *Subject:* [onap-discuss] Questions on the ONAP R2+ Resource IM
>>>
>>>
>>>
>>> Dear Jimmy, Andy and Kevin
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_-7Eks0567=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=3UIWLh7P2rAFm1qdZ7jMYQ=DbssT-o1dpLv7XFdBf9mssaQbsxlSnlqaWzswYhP6ws=ZB3dq-yjpATtQpVg2ouQJGL7G0nAaG5DV3y5DUSS2F4=>
>>> ,
>>>
>>> As discussed in the modeling call, there’re several questions regarding
>>> the resource IM that need to be answered. Please find them below:
>>>
>>>To Andy & Kevin,
>>>
>>> 1)Regarding the design time model (the figure shows the
>>> relationship between ServiceDesc, ServiceComponentDesc,
>>> ResourceCatalogItem, VNFDesc and VNFCDesc), the AID document states that "a
>>> service component has a zero to many relationship to service while the vnf
>>> component has is related to exactly one vnf". What's the case for a service
>>> component to have zero relationship to service? Does it imply that a
>>> service component can exist alone (without being involved in a service) in
>>> design time?
>>>
>>> [AJM] Service Component Descriptors may exist independently from the
>>> Service Descriptor since they may be created as “building blocks”
>>> representing specific types of service functionality (e.g., firewall
>>> functionality) used to construct Service Descriptors. Also, a Service
>>> Component Descriptor may be employed by for than one Service Descriptor.
>>> For VNFC Descriptors, the VNFC Descriptor is dependent on the containing
>>> VNF Descriptor for its existence, and the VNFC Descriptor is not shared
>>> across VNF Descriptors.
>>>
>>> 2)Regarding the vNF deployment diagram figure (the run time model):
>>>
>>> a)  It seems it’s not updated like the design time model, do you
>>> have any plan to align it to the design time model?
>>>
>>>

Re: [onap-discuss] Questions on the ONAP R2+ Resource IM

2017-11-22 Thread John Strassner

There are a number of reasons, but the most important are:

   1) The Decorator enables attributes and/or methods to be used to
construct a new object dynamically at runtime; the composite is fixed at
design time
   2) The Decorator enables one to use all or part of an object to build a
new object. The composite, like the ONF spec pattern and the TMF spec
pattern, is restricted to using the entire object.


regards,
John

On Wed, Nov 22, 2017 at 3:44 PM, 邓灵莉 <denglin...@chinamobile.com> wrote:

> I believe we are using the composite pattern currently.
> Why the decorator pattern would be better?
>
> Lingli
>
>
> 发自网易邮箱大师
> On 11/23/2017 05:03, John Strassner <straz...@gmail.com> wrote:
>
> While I agree with the requirements that Andy said (e.g., a
> ServiceComponent should support multiple Services, and a ServiceComponent
> should exist independent of a Service),
>
>1) this is assuming that a ServiceComponent is as defined in the MEF
>2) I don't think the existing model works - you either need a composite
> pattern or a decorator pattern to do this correctly
>
> Of the two, I believe that a decorator pattern is better suited (that's
> how we modeled this in the MEF).
>
> regards,
> John
>
> On Wed, Nov 22, 2017 at 11:15 AM, MAYER, ANDREW J <am8...@att.com> wrote:
>
>> Xu,
>>
>>
>>
>> Thank you for the questions. I provided a partial answer in-line with
>> your questions.
>>
>>
>>
>> Best Regards,
>> Andy
>>
>>
>>
>> *Andy Mayer, Ph.D. *| PMTS, D2.0 Integration | AT Labs | Phone: +1
>> (732) 420-9945 <(732)%20420-9945> | am8...@att.com
>>
>>
>>
>> *From:* yangxu (H) [mailto:yang...@huawei.com]
>> *Sent:* Thursday, November 16, 2017 10:29 AM
>> *To:* MAYER, ANDREW J <am8...@att.com>; FORSYTH, JAMES <jf2...@att.com>;
>> SCAGGS, KEVIN <ks0...@att.com>
>> *Cc:* onap-discuss@lists.onap.org
>> *Subject:* [onap-discuss] Questions on the ONAP R2+ Resource IM
>>
>>
>>
>> Dear Jimmy, Andy and Kevin
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_-7Eks0567=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=3UIWLh7P2rAFm1qdZ7jMYQ=DbssT-o1dpLv7XFdBf9mssaQbsxlSnlqaWzswYhP6ws=ZB3dq-yjpATtQpVg2ouQJGL7G0nAaG5DV3y5DUSS2F4=>
>> ,
>>
>> As discussed in the modeling call, there’re several questions regarding
>> the resource IM that need to be answered. Please find them below:
>>
>>To Andy & Kevin,
>>
>> 1)Regarding the design time model (the figure shows the relationship
>> between ServiceDesc, ServiceComponentDesc, ResourceCatalogItem, VNFDesc and
>> VNFCDesc), the AID document states that "a service component has a zero to
>> many relationship to service while the vnf component has is related to
>> exactly one vnf". What's the case for a service component to have zero
>> relationship to service? Does it imply that a service component can exist
>> alone (without being involved in a service) in design time?
>>
>> [AJM] Service Component Descriptors may exist independently from the
>> Service Descriptor since they may be created as “building blocks”
>> representing specific types of service functionality (e.g., firewall
>> functionality) used to construct Service Descriptors. Also, a Service
>> Component Descriptor may be employed by for than one Service Descriptor.
>> For VNFC Descriptors, the VNFC Descriptor is dependent on the containing
>> VNF Descriptor for its existence, and the VNFC Descriptor is not shared
>> across VNF Descriptors.
>>
>> 2)Regarding the vNF deployment diagram figure (the run time model):
>>
>> a)  It seems it’s not updated like the design time model, do you
>> have any plan to align it to the design time model?
>>
>> [AJM] We are currently updating the Run-Time diagram to align.
>>
>> b) For the current figure, we want to know the answers for:
>>
>>i.  What's the relationship between
>> VNFC instance and VNF module? What's the usage of VNF module?
>>
>>   ii.  Why does network only associate
>> with the VM, but not with Docker/LXC? Why is the cardinality 1:1?
>>
>>  iii.  Why does storage have no
>> association with VNFC instance?
>>
>>  iv.  Why does VNFImage have 1:1
>> association with VNF instance, instead of VNFC instance?
>>
>>   v.  No model for network port?
>>
>> To Jimmy,
>>
>>

Re: [onap-discuss] Questions on the ONAP R2+ Resource IM

2017-11-22 Thread John Strassner

While I agree with the requirements that Andy said (e.g., a
ServiceComponent should support multiple Services, and a ServiceComponent
should exist independent of a Service),

   1) this is assuming that a ServiceComponent is as defined in the MEF
   2) I don't think the existing model works - you either need a composite
pattern or a decorator pattern to do this correctly

Of the two, I believe that a decorator pattern is better suited (that's how
we modeled this in the MEF).

regards,
John

On Wed, Nov 22, 2017 at 11:15 AM, MAYER, ANDREW J  wrote:

> Xu,
>
>
>
> Thank you for the questions. I provided a partial answer in-line with your
> questions.
>
>
>
> Best Regards,
> Andy
>
>
>
> *Andy Mayer, Ph.D. *| PMTS, D2.0 Integration | AT Labs | Phone: +1
> (732) 420-9945 <(732)%20420-9945> | am8...@att.com
>
>
>
> *From:* yangxu (H) [mailto:yang...@huawei.com]
> *Sent:* Thursday, November 16, 2017 10:29 AM
> *To:* MAYER, ANDREW J ; FORSYTH, JAMES ;
> SCAGGS, KEVIN 
> *Cc:* onap-discuss@lists.onap.org
> *Subject:* [onap-discuss] Questions on the ONAP R2+ Resource IM
>
>
>
> Dear Jimmy, Andy and Kevin
> 
> ,
>
> As discussed in the modeling call, there’re several questions regarding
> the resource IM that need to be answered. Please find them below:
>
>To Andy & Kevin,
>
> 1)Regarding the design time model (the figure shows the relationship
> between ServiceDesc, ServiceComponentDesc, ResourceCatalogItem, VNFDesc and
> VNFCDesc), the AID document states that "a service component has a zero to
> many relationship to service while the vnf component has is related to
> exactly one vnf". What's the case for a service component to have zero
> relationship to service? Does it imply that a service component can exist
> alone (without being involved in a service) in design time?
>
> [AJM] Service Component Descriptors may exist independently from the
> Service Descriptor since they may be created as “building blocks”
> representing specific types of service functionality (e.g., firewall
> functionality) used to construct Service Descriptors. Also, a Service
> Component Descriptor may be employed by for than one Service Descriptor.
> For VNFC Descriptors, the VNFC Descriptor is dependent on the containing
> VNF Descriptor for its existence, and the VNFC Descriptor is not shared
> across VNF Descriptors.
>
> 2)Regarding the vNF deployment diagram figure (the run time model):
>
> a)  It seems it’s not updated like the design time model, do you have
> any plan to align it to the design time model?
>
> [AJM] We are currently updating the Run-Time diagram to align.
>
> b) For the current figure, we want to know the answers for:
>
>i.  What's the relationship between
> VNFC instance and VNF module? What's the usage of VNF module?
>
>   ii.  Why does network only associate
> with the VM, but not with Docker/LXC? Why is the cardinality 1:1?
>
>  iii.  Why does storage have no
> association with VNFC instance?
>
>  iv.  Why does VNFImage have 1:1
> association with VNF instance, instead of VNFC instance?
>
>   v.  No model for network port?
>
> To Jimmy,
>
>   First thank you and Pamela for the comments you provided last
> time, I updated several questions afterwards, shown below:
>
> 1)Is the orchestration-status of the VNFC similar to the vnfcState
> defined in ETSI? (vnfcState describes the state of a VNFC instance,
> possible values are: STARTED, STOPPED. STARTED means the VNFC instance is
> up and running, and STOPPED means the VNFC instance has been shut down (but
> not terminated/deleted). Similar to the VM power on/off concept)
>
> 2)Please clarify more on the operational-status of VNF, are the valid
> values “in-service-path” and “out-of-service-path”? and what do they mean?
>
> 3)Orchestration-status of the VNF is also not clear to us, could you
> elaborate more on the usage of it? For example, the valid values?
>
>
>
> Thank you all for the help!
>
> Best regards,
>
> Xu
>
> ___
> onap-discuss mailing list
> onap-discuss@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-discuss
>
>


-- 
regards,
John
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [onap-tsc] 答复: Official ONAP Architecture Slide

2017-11-13 Thread John Strassner

Works fine for me!

regards,
John

On Mon, Nov 13, 2017 at 4:23 PM, Kenny Paul 
wrote:

> are these 404 errors?
>
> Best Regards,
> -kenny
>
> *Kenny Paul,  Technical Program Manager*
> *kp...@linuxfoundation.org *
> *510.766.5945 <(510)%20766-5945>*
>
> On Nov 13, 2017, at 4:22 PM, Yunxia Chen  wrote:
>
> I got page not found error from that link as well.
> Helen Chen
>
>
> Sent from HUAWEI AnyOffice
> *From: *邓灵莉/Lingli Deng
> *To: *Kenny Paul; onap-discuss; onap-tsc;
> *Cc: *Lisa Caywood;
> *Subject: *[onap-tsc] 答复: Official ONAP Architecture Slide
> *Time: *2017-11-14 08:15:03
>
>
> Hi Kenny
>
>
> I am a raid that the link returns a error as Page not found.
>
>
> Lingli
>
>
> 发送自 Windows 10 版邮件 应用
>
>
> *发件人: *Kenny Paul 
> *发送时间: *2017年11月14日 8:04
> *收件人: *onap-discuss ; onap-tsc
> 
> *抄送: *Lisa Caywood 
> *主题: *[onap-tsc] Official ONAP Architecture Slide
>
>
> As was pointed out in Paris there are too many variations of the Amsterdam
> architecture which is bad to say the least.
> The officially approved image for the Amsterdam Architecture and be found
> here:
> https://wiki.onap.org/download/attachments/1015842/
> ONAP%20Amsterdam%20arch.png?api=v2
>
>
>
>
>
>
> In preparation for the release announcement here is what we are asking in
> order of priority:
>
>
>
> -If an archecture image is referecned in your official readthedocs
> documentation, please use this image
>
>
> -If an archecture image is referenced in your wiki pages,  please add the
> URL above to reference the the image.
>
>
> -If an archecture image is referecned in a presentation slide deck, please
> ensure you use this image.
>
>
>
> I am intentionally NOT distributing it because that is how we ended up
> with so many versions in the first place. :-)
>
>
> Thanks!
>
>
>
>
>
>
> Best Regards,
> -kenny
>
> *Kenny Paul,  Technical Program Manager*
> *kp...@linuxfoundation.org *
> *510.766.5945 <(510)%20766-5945>*
>
>
>
> ___
> onap-discuss mailing list
> onap-discuss@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-discuss
>
>


-- 
regards,
John
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [Modeling] ONAP Modeling workshop proposal

2017-11-02 Thread John Strassner

Hi Deng,

I am the Chair of Modeling efforts in the MEF, and a TMF Distinguished
Fellow. I will be available to present MEF modeling strategies and
recommendations to help ONAP.

regards,
John

John Strassner, Ph.D.
Chair, Modeling, MEF
Co-Chair, Intent WG, MEF
Rapporteur, Architecture, ETSI ISG ENI
TMF Distinguished Fellow
CTO, Software Lab, Huawei

On Thu, Nov 2, 2017 at 8:49 AM, denghui (L) <denghu...@huawei.com> wrote:

> Hello all
>
>
>
> Modeling subcommittee is in the very tight schedule, plan to have R2
> modeling ready by December and intends to call for feedback from SDOs and
> identify potential cooperation areas. And many SDOs propose to collaborate
> with ONAP such as MEF/TMF/ETSI NFV, and in order to avoid the confliction
> with other sessions in Forum, propose to have 1 day workshop right after
> Forum.
>
>
>
> Program could be:
>
> u ONAP modeling overview
>
> u SDOs input & feedback
>
> u Collaboration discussion
>
>
>
> Time: Dec. 14th 2017 (Thursday ）
>
> Location: Because Intel and Cablelabs can’t host it on Thursday, suggest
> Huawei office in Santa Clara
>
>
>
> Please kindly help to feedback by the end of this Friday, we are seeking
> for whether there is a serious issue or not.
>
>
>
> Thanks a lot for your contribution
>
> Best regards,
>
>
>
> DENG Hui
>
> ___
> onap-discuss mailing list
> onap-discuss@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-discuss
>
>


-- 
regards,
John
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [onap-tsc] Tentative July ONAP Developers Face-to-Face Meeting

2017-06-13 Thread John Strassner

There wasn't a time zone on the Doodle.

July 17-21 is the IETF in Prague, July 24-28 is the MEF Q3 in Toronto. I'd
personally vote for August but it wasn't listed. :-)

best,
John

On Mon, Jun 12, 2017 at 8:41 PM, Gadiyar, Rajesh 
wrote:

> +1 Good idea ☺
>
>
>
> *From: * on behalf of "GILBERT, MAZIN E
> (MAZIN E)" 
> *Date: *Monday, June 12, 2017 at 2:01 PM
> *To: *Kenny Paul 
> *Cc: *"onap-discuss@lists.onap.org" ,
> onap-tsc 
> *Subject: *Re: [onap-tsc] [onap-discuss] Tentative July ONAP Developers
> Face-to-Face Meeting
>
>
>
> I was not present for this discussion. We need to have a meeting around
> the 3rd week of
>
> July to go through project by project progress. Phil and I discussed a
> virtual meeting
>
> since folks will be too busy to travel, and some may not be able to.
>
>
>
> Would like to get a sense from the TSC community if this is appropriate
> and more
>
> convenient while voting for dates.
>
>
>
> thanks
>
> Mazin
>
>
>
> On Jun 12, 2017, at 1:08 PM, Kenny Paul  wrote:
>
>
>
> Please respond to the doodle poll below no later than:
>
> *Thurs. 01:00 PM UTC*
>
> *Thurs. 09:00 PM China*
>
> *Thurs: 09:00 AM Eastern*
>
> *Thurs: 06:00 AM Pacific*
>
>
>
> https://doodle.com/poll/7zufivqebtnvrhdt
> 
>
>
>
> Thank You.
>
>
>
> Best Regards,
> -kenny
>
> Kenny Paul,  Technical Program Manager
> kp...@linuxfoundation.org
> 510.766.5945 <(510)%20766-5945>
>
>
>
> ___
> onap-discuss mailing list
> onap-discuss@lists.onap.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.
> onap.org_mailman_listinfo_onap-2Ddiscuss=DwICAg=
> LFYZ-o9_HUMeMTSQicvjIg=IKSC5mg8GeOiSar1dax3GQ=
> 7n6f3RBF3LtkjuBpPhqrMbVfiHC_wqVOfDz5z3uutjM=8D2aZuG-
> pN820woJDvlHxyXQnkAsRt0bFjokAPWgc1E=
>
>
>
> ___
> ONAP-TSC mailing list
> onap-...@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-tsc
>
>


-- 
regards,
John
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [modeling] ONAP Modeling Guidelines

Re: [onap-discuss] [modeling] Papyrus version

Re: [onap-discuss] [modeling] ONAP modeling workshop program

Re: [onap-discuss] Questions on the ONAP R2+ Resource IM

Re: [onap-discuss] Questions on the ONAP R2+ Resource IM

Re: [onap-discuss] Questions on the ONAP R2+ Resource IM

Re: [onap-discuss] Questions on the ONAP R2+ Resource IM

Re: [onap-discuss] [onap-tsc] 答复: Official ONAP Architecture Slide

Re: [onap-discuss] [Modeling] ONAP Modeling workshop proposal

Re: [onap-discuss] [onap-tsc] Tentative July ONAP Developers Face-to-Face Meeting

10 matches

Site Navigation

Mail list logo

Footer information