from:"BULLARD, GIL"

Re: [onap-discuss] Invitation: 5G Use Case Team Meeting @ Weekly from 8am to 9am on Thursday from Thu Jan 4 to Thu Dec 13 (PST) (onap-discuss@lists.onap.org)

2018-01-25 Thread BULLARD, GIL

Thank you Ben, Sigmar, the presentation today was very informative!

Here are some notes I took on the impact to ONAP.  Hopefully

*   Both RAN and Core NFs are “tracking area aware”.  And a slice must be 
“consistently configured” throughout a tracking area.   It inadvisable (or 
impossible?) to configure a slice on just a subset of a tracking area.  Thus, 
the lowest level of granularity of “scope” that a slice can be mapped to is a 
tracking area.
*   So it sounds like we need to model an object type in A&AI that 
represents a "Tracking Area", and need to allow (an easy) way for a service 
provider to maintain the association between a (RAN or Core) NF and the 
Tracking Areas that it supports.
*   Thus, when a (RAN or Core) NF is instantiated the service provider must 
enter the “list of” tracking areas that the NF is intended to supports.
*   When ONAP receives a request to create a slice instance, the request 
must include a list of Tracking Areas in which that slice should be configured. 
 ONAP would use A&AI to map that request into a list of RAN and Core NFs that 
need to be configured.  Perhaps to make it less cumbersome on the GUI user, 
ONAP should also allow the service provider to define an arbitrarily deep 
hierarchy of container objects in A&AI to that would at the “bottom” resolve to 
a list of tracking areas.
*   So, it sounds like ONAP has no need to track the association of 
tracking area to cell, and in fact ONAP has no need to even be aware of cells 
at all.  This implies that ONAP need not track the association between a cell 
and the frequencies it supports.
*   We confirmed that, as the wiki Slicing use case states, it is possible 
for an ONAP service designer to define a “slice type” that maps to a certain 
(set of) frequenc(ies), like the “Red” and “Blue” frequencies example.  
However, because ONAP doesn’t track cells, much less the frequencies of the 
cells, there is no way for ONAP to validate that the set of tracking areas 
included in a “slice instantiation request” is actually consistent with the 
frequency map for that slice type.  E.g., ONAP would not know if a user tries 
to instantiate a slice type that is restricted to “Red frequencies” in a 
tracking area that has no cells that use the “Red frequencies”.  We decided 
this is okay, presumably because whoever is providing the list of tracking 
areas to ONAP has “non-ONAP” ways of verifying the consistency between the 
frequency definition of a slice type and the characteristics of the tracking 
area in which they want that slice instantiated.
*   As mentioned above, it is inadvisable (or impossible?) to configure a 
slice on just a portion of a tracking area.  Thus, when configuring a slice in 
a tracking area it is important that ONAP apply/activate the configuration of 
that new slice on all CUs (for example) in that tracking area at exactly the 
same time.  We didn’t discuss the adverse effects of race conditions in this 
regard.
*   We need a way to allow a service provider to redefine the mapping 
between a (RAN or Core) NF to the tracking areas that it supports.  Such 
redefinition could trigger ONAP “mass update” activity.  E.g., if a tracking 
area is added/removed from a CU then ONAP will need to determine if that action 
resulted in a change in the set of slice instances that the CU should support, 
and if so reconfigure the CU accordingly to add/remove the appropriate slices.


-Original Appointment-
From: ONAP Meetings and Events 
[mailto:linuxfoundation.org_1rmtb5tpr3uc8f76fmflplo...@group.calendar.google.com]
Sent: Wednesday, January 03, 2018 7:44 PM
To: ONAP Meetings and Events; onap-discuss@lists.onap.org; BEGWANI, VIMAL
Subject: [onap-discuss] Invitation: 5G Use Case Team Meeting @ Weekly from 8am 
to 9am on Thursday from Thu Jan 4 to Thu Dec 13 (PST) 
(onap-discuss@lists.onap.org)
When: Thursday, January 25, 2018 11:00 AM-12:00 PM America/New_York.
Where: https://zoom.us/j/478423919


more details 
>

5G Use Case Team Meeting
When
Weekly from 8am to 9am on Thursday from Thu Jan 4 to Thu Dec 13 Pacific 
Time

Where

https://zoom.us/j/478423919
 
(map

Re: [onap-discuss] vCPE deep dive session in Paris

2017-09-25 Thread BULLARD, GIL

I agree with Yoav, let’s keep the session at its current timeslot.

From: Casem Majd (Cas Majd) [mailto:cas.m...@huawei.com]
Sent: Monday, September 25, 2017 6:48 AM
To: KLUGER, YOAV ; BULLARD, GIL ; Kang 
Xi 
Cc: onap-discuss@lists.onap.org; ZINNIKAS, MICHAEL J ; CHOMA, 
JOHN S ; DAUGHERTY, ROBERT E ; TIMONEY, DAN 
; ZITELLA, MICHAEL V ; DeWayne Filppi 
; NEKRASSOV, ALEXEI ; SHAH, SARYU D 
; MARTELLA, ARTHUR 
Subject: RE: vCPE deep dive session in Paris

An alternative is to record the session for remote attendees.

From: 
onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Yoav Kluger
Sent: Saturday, September 23, 2017 5:03 AM
To: BULLARD, GIL; Kang Xi
Cc: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; ZINNIKAS, 
MICHAEL J; CHOMA, JOHN S; DAUGHERTY, ROBERT E; TIMONEY, DAN; ZITELLA, MICHAEL 
V; DeWayne Filppi; NEKRASSOV, ALEXEI; SHAH, SARYU D; MARTELLA, ARTHUR
Subject: Re: [onap-discuss] vCPE deep dive session in Paris

Kang, all,

The big advantage of the current time slot (12:30-13:15) is that there is no 
other discussion currently planned for this slot, which will allow many people 
to attend.
In the time slot you propose to move it to there are already 3 interesting 
sessions scheduled, which will result in many people missing our session even 
though they would be interested in joining.
As for time zones I think 6:30am for eastern U.S. is reasonable, and in 
particular Gil will attend, and we would only lose potential remote 
participants in other u.s. time zones.

So between definitely losing many people locally, vs. potentially losing some 
remotely – I prefer the latter, i.e. to not move our session.

Yoav

From: BULLARD, GIL [mailto:wb5...@att.com]
Sent: Friday, September 22, 2017 10:23 PM
To: Kang Xi mailto:kang...@huawei.com>>; Yoav Kluger 
mailto:yoav.klu...@amdocs.com>>
Cc: Yunxia Chen mailto:helen.c...@huawei.com>>; 
SPATSCHECK, OLIVER mailto:spat...@research.att.com>>; 
LEFEVRE, CATHERINE mailto:cl6...@intl.att.com>>; JI, 
LUSHENG mailto:l...@research.att.com>>; CHOMA, JOHN S 
mailto:jc1...@att.com>>; Zhou, Danny 
mailto:danny.z...@intel.com>>; PLATANIA, MARCO 
mailto:plata...@research.att.com>>; FREEMAN, BRIAN D 
mailto:bf1...@att.com>>; SHACHAM, RON 
mailto:rshac...@research.att.com>>; ZINNIKAS, 
MICHAEL J mailto:mz2...@att.com>>; SHAH, SARYU D 
mailto:ss3...@att.com>>; NEKRASSOV, ALEXEI 
mailto:an4...@att.com>>; VENKATESH KUMAR, VIJAY 
mailto:vv7...@att.com>>; ROSE, DANIEL V 
mailto:dr6...@att.com>>; TIMONEY, DAN 
mailto:dt5...@att.com>>; ZITELLA, MICHAEL V 
mailto:mz1...@att.com>>; DAUGHERTY, ROBERT E 
mailto:rd4...@att.com>>; Pawlowski Michal 1 - Korpo 
mailto:michal.pawlows...@orange.com>>; Yoav 
Kluger mailto:yoav.klu...@amdocs.com>>; Li, Johnson 
mailto:johnson...@intel.com>>; Geora Barsky 
mailto:geo...@amdocs.com>>; MARTELLA, ARTHUR 
mailto:amart...@research.att.com>>; DeWayne Filppi 
mailto:dewa...@cloudify.co>>; Alla Goldner 
mailto:alla.gold...@amdocs.com>>
Subject: RE: vCPE deep dive session in Paris

Kang,
I can support either time.

Note that I have posted to the “drafts” page on the wiki the slides that I plan 
to talk from:
https://wiki.onap.org/display/DW/Residential+Broadband+vCPE+Drafts+for+discussion?focusedCommentId=15997611&refresh=1506107321110#comment-15997611<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Residential-2BBroadband-2BvCPE-2BDrafts-2Bfor-2Bdiscussion-3FfocusedCommentId-3D15997611-26refresh-3D1506107321110-23comment-2D15997611&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6llaOBbLWNSasQ9_ejgubw&m=ovvrkFG6QuzvJudkfRpBj1gcHHoeQlRH7K6rxsLsYnw&s=S3YDjMz6iUPMlqeZrsfZzvSEUlV_K9eqv5DijlmPRqk&e=>

As an FYI, you will see that the slides have a lot of information, but do not 
conclude that I will attempt to talk to that detail in my allotted 15 minutes.  
I have purposely shrunk pictures down to small font so that no one in the 
audience is tempted to try to read that detail during the presentation.  My 
purpose is to use the diagrams on the slide only to generally convey the topic 
which I will be addressing verbally.  I will ask the audience to focus only on 
the boxes and sticks... no fine text on the slides.  I plan to basically speak 
to the verbiage in the yellow callouts, which capture the “take away” points on 
each slide.  The audience can come back and read the details later if they 
would like.

Team,
Please comment if you have any feedback on the slides.  Comments are 
appreciated.  Particularly:

• DeWayne - can you verify that I have done a good job in my yellow 
callout text of articulating our “Stretch” goal for Release 1?

• Dan T, Rob D, John C, Daniel R – can you verify that I have done a 
good

Re: [onap-discuss] [integration][so] vCPE workflow discussion

2017-09-06 Thread BULLARD, GIL

Good news, thank you Christina.  Quick follow up to verify that you are talking 
about R1 ONAP, right?  Is that something that AT&T can do?
Thank you!
Gil

_
From: MONTELEONE, CHRISTINA
Sent: Wednesday, September 06, 2017 8:24 AM
To: BULLARD, GIL ; Kang Xi ; 
onap-discuss@lists.onap.org; DAUGHERTY, ROBERT E ; KLUGER, YOAV 
; TIMONEY, DAN ; CHOMA, JOHN S 
; SHAH, SARYU D ; MOHAPATRA, SANJEETA 
; GUNTAKA, YUGANDHAR ; FORSYTH, JAMES 

Cc: ZINNIKAS, MICHAEL J 
Subject: RE: [integration][so] vCPE workflow discussion

Hi Gil,
I don't see any issue with adding MAC address to p-interfaces.
We could also add a query to help simplify this parent lookup: P-interface (by 
mac-address) to pnf.

Thank you,
Christina Monteleone
Professional-Tech Requirements Mgmt
Flex Force
732.420.3639

_____
From: BULLARD, GIL
Sent: Thursday, August 31, 2017 3:54 PM
To: Kang Xi mailto:kang...@huawei.com>>; 
onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; DAUGHERTY, 
ROBERT E mailto:rd4...@att.com>>; KLUGER, YOAV 
mailto:yoav.klu...@amdocs.com>>; TIMONEY, DAN 
mailto:dt5...@att.com>>; CHOMA, JOHN S 
mailto:jc1...@att.com>>; SHAH, SARYU D 
mailto:ss3...@att.com>>; MOHAPATRA, SANJEETA 
mailto:sm1...@att.com>>; MONTELEONE, CHRISTINA 
mailto:cm3...@att.com>>
Cc: ZINNIKAS, MICHAEL J mailto:mz2...@att.com>>
Subject: RE: [integration][so] vCPE workflow discussion
Importance: High

Team,
I talked with Yoav who had some good suggestions on how to minimize the 
departure from "reality" with the introduction of the Allotted Resource model 
for a BRG and solve the A&AI problem I mentioned before.  I won't get a chance 
to update my slides before I leave for vacation, but here are the highlights of 
the changes:

1)  Slide 4, the vCpeResCust model, remains as I have shown it on the most 
recent deck on the wiki link below.
2)  Slide 40, however, will change in the following ways:
a.  In the Release 1 "Alt" flow, SDNC will continue to create a PNF object 
in A&AI as I had showed before.  However, this PNF object will not be 
associated with the vCpeResCust service, nor will it appear in the vCpeResCust 
service model (hence no changes to slide 4).  Nor will it in fact be associated 
with any Service object in Release 1.  SDNC will continue to write both the MAC 
Address and WAN IP to this PNF object.
b.  I found out the A&AI PNF object doesn't have a MAC Address attribute.  
Nor does the P-Interface object.  Only the L-Interface object has a MAC 
Address. This seems strange to Yoav and I since for a PNF the MAC Address it 
seems really should be associated with a P-Interface, and not only with an 
L-Interface.
i.  Christina, can we get A&AI to add MAC Address to P-Interface?
c.  SDNC will search A&AI for BRGs by searching for PNFs such that that MAC 
Address appears on a P-Interface of that PNF.
i.  Christina, can we get A&AI to support such a search in R1?
3)  Slide 45 will change in the following ways:
a.  SO will pass the BRG_WAN_MAC_Address to SDNC with the "Assign" for the 
BRG Allotted Resource.
b.  As part of "Assign" processing for the BRG AR, SDNC will search A&AI by 
MAC Address for the BRG PNF with that MAC address (see query above).  SDNC will 
obtain the WAN IP from the associated PNF.  In effect, SDNC will be treating 
the A&AI PNF object as the "pool" from which to assign the WAN IP for that 
Allotted Resource object.
c.  Yoav makes a good point that, for an Allotted Resource that consumes an 
entire VNF (as in this case), the Allotted Resource doesn't really need to be 
"created"; rather it pre-exists with the VNF instantiation.  He suggests 
therefore that the "Create" operation on the AR be a "no-op" and the "Activate" 
operation  be what drives the configuration of the vBRG_EMU VNF.
i.  John C, Dan T, do you agree?
ii. Dan T, for an Allotted Resource that consumes the entire VNF, should 
the WAN IP that is used to configure that Allotted Resource be modeled on the 
(parent) VNF object or the Allotted Resource object, or both?  Depending on the 
answer here, perhaps in "3b" above SDNC should also update the WAN IP on the 
corresponding vBRG_EMU VNF object?

Yoav, please feel free to add anything that I might have missed.

I will update the slides to reflect these changes on Tuesday when I return.  
Have a great weekend all!
Gil

_
From: BULLARD, GIL
Sent: Thursday, August 31, 2017 1:05 PM
To: 'Kang Xi' mailto:kang...@huawei.com>>; 
'onap-discuss@lists.onap.org' 
mailto:onap-discuss@lists.onap.org>>; DAUGHERTY, 
ROBERT E mailto:rd4...@att.com>>; KLUGER, YOAV 
mailto:yoav.klu...@amdocs.

Re: [onap-discuss] [integration][so] vCPE workflow discussion

2017-09-05 Thread BULLARD, GIL

Team,
I have made the changes described below and uploaded the deck to the vCPE use 
case "drafts for discussion" page:
https://wiki.onap.org/display/DW/Residential+Broadband+vCPE+Drafts+for+discussion?focusedCommentId=15992837&refresh=1504629237289#comment-15992837
Please comment.
Thanks,
Gil

_____
From: BULLARD, GIL
Sent: Thursday, August 31, 2017 3:54 PM
To: 'Kang Xi' ; 'onap-discuss@lists.onap.org' 
; DAUGHERTY, ROBERT E ; KLUGER, 
YOAV ; TIMONEY, DAN ; CHOMA, JOHN S 
; SHAH, SARYU D ; MOHAPATRA, SANJEETA 
; MONTELEONE, CHRISTINA 
Cc: ZINNIKAS, MICHAEL J 
Subject: RE: [integration][so] vCPE workflow discussion
Importance: High


Team,
I talked with Yoav who had some good suggestions on how to minimize the 
departure from "reality" with the introduction of the Allotted Resource model 
for a BRG and solve the A&AI problem I mentioned before.  I won't get a chance 
to update my slides before I leave for vacation, but here are the highlights of 
the changes:

1)  Slide 4, the vCpeResCust model, remains as I have shown it on the most 
recent deck on the wiki link below.
2)  Slide 40, however, will change in the following ways:
a.  In the Release 1 "Alt" flow, SDNC will continue to create a PNF object 
in A&AI as I had showed before.  However, this PNF object will not be 
associated with the vCpeResCust service, nor will it appear in the vCpeResCust 
service model (hence no changes to slide 4).  Nor will it in fact be associated 
with any Service object in Release 1.  SDNC will continue to write both the MAC 
Address and WAN IP to this PNF object.
b.  I found out the A&AI PNF object doesn't have a MAC Address attribute.  
Nor does the P-Interface object.  Only the L-Interface object has a MAC 
Address. This seems strange to Yoav and I since for a PNF the MAC Address it 
seems really should be associated with a P-Interface, and not only with an 
L-Interface.
i.  Christina, can we get A&AI to add MAC Address to P-Interface?
c.  SDNC will search A&AI for BRGs by searching for PNFs such that that MAC 
Address appears on a P-Interface of that PNF.
i.  Christina, can we get A&AI to support such a search in R1?
3)  Slide 45 will change in the following ways:
a.  SO will pass the BRG_WAN_MAC_Address to SDNC with the "Assign" for the 
BRG Allotted Resource.
b.  As part of "Assign" processing for the BRG AR, SDNC will search A&AI by 
MAC Address for the BRG PNF with that MAC address (see query above).  SDNC will 
obtain the WAN IP from the associated PNF.  In effect, SDNC will be treating 
the A&AI PNF object as the "pool" from which to assign the WAN IP for that 
Allotted Resource object.
c.  Yoav makes a good point that, for an Allotted Resource that consumes an 
entire VNF (as in this case), the Allotted Resource doesn't really need to be 
"created"; rather it pre-exists with the VNF instantiation.  He suggests 
therefore that the "Create" operation on the AR be a "no-op" and the "Activate" 
operation  be what drives the configuration of the vBRG_EMU VNF.
i.  John C, Dan T, do you agree?
ii. Dan T, for an Allotted Resource that consumes the entire VNF, should 
the WAN IP that is used to configure that Allotted Resource be modeled on the 
(parent) VNF object or the Allotted Resource object, or both?  Depending on the 
answer here, perhaps in "3b" above SDNC should also update the WAN IP on the 
corresponding vBRG_EMU VNF object?

Yoav, please feel free to add anything that I might have missed.

I will update the slides to reflect these changes on Tuesday when I return.  
Have a great weekend all!
Gil

_
From: BULLARD, GIL
Sent: Thursday, August 31, 2017 1:05 PM
To: 'Kang Xi' mailto:kang...@huawei.com>>; 
'onap-discuss@lists.onap.org' 
mailto:onap-discuss@lists.onap.org>>; DAUGHERTY, 
ROBERT E mailto:rd4...@att.com>>; KLUGER, YOAV 
mailto:yoav.klu...@amdocs.com>>
Cc: ZINNIKAS, MICHAEL J mailto:mz2...@att.com>>
Subject: RE: [integration][so] vCPE workflow discussion


Team,
I made some updates that result in the BRG Allotted Resource Resource-Level 
flow looking like the TunnelXConn Allotte Resource Resource-Level flow, which 
is appropriate and necessary in fact.  I also updated the BRG_EMU Service-Level 
flow to clarify that now Robot must remember the BRG_EMU Service Instance UUID 
for its use when wearing the "Homing Emulator" hat.

https://wiki.onap.org/display/DW/Residential+Broadband+vCPE+Drafts+for+discussion?refresh=1504129602127&focusedCommentId=15991828&refresh=1504196505842#comment-15991828

FYI,
Gil

_
From: BULLARD, GIL
Sent: Wednesday, August 30, 2017 5:49 PM
To: 'K

Re: [onap-discuss] [integration][so] vCPE workflow discussion

2017-09-01 Thread BULLARD, GIL

Team,
I talked with Yoav who had some good suggestions on how to minimize the 
departure from "reality" with the introduction of the Allotted Resource model 
for a BRG and solve the A&AI problem I mentioned before.  I won't get a chance 
to update my slides before I leave for vacation, but here are the highlights of 
the changes:

1)  Slide 4, the vCpeResCust model, remains as I have shown it on the most 
recent deck on the wiki link below.
2)  Slide 40, however, will change in the following ways:
a.  In the Release 1 "Alt" flow, SDNC will continue to create a PNF object 
in A&AI as I had showed before.  However, this PNF object will not be 
associated with the vCpeResCust service, nor will it appear in the vCpeResCust 
service model (hence no changes to slide 4).  Nor will it in fact be associated 
with any Service object in Release 1.  SDNC will continue to write both the MAC 
Address and WAN IP to this PNF object.
b.  I found out the A&AI PNF object doesn't have a MAC Address attribute.  
Nor does the P-Interface object.  Only the L-Interface object has a MAC 
Address. This seems strange to Yoav and I since for a PNF the MAC Address it 
seems really should be associated with a P-Interface, and not only with an 
L-Interface.
i.  Christina, can we get A&AI to add MAC Address to P-Interface?
c.  SDNC will search A&AI for BRGs by searching for PNFs such that that MAC 
Address appears on a P-Interface of that PNF.
i.  Christina, can we get A&AI to support such a search in R1?
3)  Slide 45 will change in the following ways:
a.  SO will pass the BRG_WAN_MAC_Address to SDNC with the "Assign" for the 
BRG Allotted Resource.
b.  As part of "Assign" processing for the BRG AR, SDNC will search A&AI by 
MAC Address for the BRG PNF with that MAC address (see query above).  SDNC will 
obtain the WAN IP from the associated PNF.  In effect, SDNC will be treating 
the A&AI PNF object as the "pool" from which to assign the WAN IP for that 
Allotted Resource object.
c.  Yoav makes a good point that, for an Allotted Resource that consumes an 
entire VNF (as in this case), the Allotted Resource doesn't really need to be 
"created"; rather it pre-exists with the VNF instantiation.  He suggests 
therefore that the "Create" operation on the AR be a "no-op" and the "Activate" 
operation  be what drives the configuration of the vBRG_EMU VNF.
i.  John C, Dan T, do you agree?
ii. Dan T, for an Allotted Resource that consumes the entire VNF, should 
the WAN IP that is used to configure that Allotted Resource be modeled on the 
(parent) VNF object or the Allotted Resource object, or both?  Depending on the 
answer here, perhaps in "3b" above SDNC should also update the WAN IP on the 
corresponding vBRG_EMU VNF object?

Yoav, please feel free to add anything that I might have missed.

I will update the slides to reflect these changes on Tuesday when I return.  
Have a great weekend all!
Gil

_
From: BULLARD, GIL
Sent: Thursday, August 31, 2017 1:05 PM
To: 'Kang Xi' ; 'onap-discuss@lists.onap.org' 
; DAUGHERTY, ROBERT E ; KLUGER, 
YOAV 
Cc: ZINNIKAS, MICHAEL J 
Subject: RE: [integration][so] vCPE workflow discussion


Team,
I made some updates that result in the BRG Allotted Resource Resource-Level 
flow looking like the TunnelXConn Allotte Resource Resource-Level flow, which 
is appropriate and necessary in fact.  I also updated the BRG_EMU Service-Level 
flow to clarify that now Robot must remember the BRG_EMU Service Instance UUID 
for its use when wearing the "Homing Emulator" hat.

https://wiki.onap.org/display/DW/Residential+Broadband+vCPE+Drafts+for+discussion?refresh=1504129602127&focusedCommentId=15991828&refresh=1504196505842#comment-15991828

FYI,
Gil

_
From: BULLARD, GIL
Sent: Wednesday, August 30, 2017 5:49 PM
To: 'Kang Xi' mailto:kang...@huawei.com>>; 
onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; DAUGHERTY, 
ROBERT E mailto:rd4...@att.com>>; KLUGER, YOAV 
mailto:yoav.klu...@amdocs.com>>
Cc: ZINNIKAS, MICHAEL J mailto:mz2...@att.com>>
Subject: RE: [integration][so] vCPE workflow discussion


Team,
I have updated the slides based upon the feedback today that modeling of BRG as 
a PNF will not be viable from an SO perspective in R1.  I have thus changed it 
to an Allotted Resource.  The updated slides can be found here:
https://wiki.onap.org/display/DW/Residential+Broadband+vCPE+Drafts+for+discussion?focusedCommentId=15991633&refresh=1504129602127#comment-15991633

Comments are appreciated.

One issue we need to work is exactly which object SDNC will update in A&AI as 
part of the BRG Event processing flow, and what will the event look l

Re: [onap-discuss] [integration][so] vCPE workflow discussion

2017-08-31 Thread BULLARD, GIL

Team,
I made some updates that result in the BRG Allotted Resource Resource-Level 
flow looking like the TunnelXConn Allotte Resource Resource-Level flow, which 
is appropriate and necessary in fact.  I also updated the BRG_EMU Service-Level 
flow to clarify that now Robot must remember the BRG_EMU Service Instance UUID 
for its use when wearing the "Homing Emulator" hat.

https://wiki.onap.org/display/DW/Residential+Broadband+vCPE+Drafts+for+discussion?refresh=1504129602127&focusedCommentId=15991828&refresh=1504196505842#comment-15991828

FYI,
Gil

_________
From: BULLARD, GIL
Sent: Wednesday, August 30, 2017 5:49 PM
To: 'Kang Xi' ; onap-discuss@lists.onap.org; DAUGHERTY, 
ROBERT E ; KLUGER, YOAV 
Cc: ZINNIKAS, MICHAEL J 
Subject: RE: [integration][so] vCPE workflow discussion


Team,
I have updated the slides based upon the feedback today that modeling of BRG as 
a PNF will not be viable from an SO perspective in R1.  I have thus changed it 
to an Allotted Resource.  The updated slides can be found here:
https://wiki.onap.org/display/DW/Residential+Broadband+vCPE+Drafts+for+discussion?focusedCommentId=15991633&refresh=1504129602127#comment-15991633

Comments are appreciated.

One issue we need to work is exactly which object SDNC will update in A&AI as 
part of the BRG Event processing flow, and what will the event look like that 
is intercepted by ROBOT.  We need to verify that Robot will be able to 
correlate this event.  I believe that this can be done because the event will 
have the BRG_EMU VNF UUID on it.
Thanks,
Gil


-Original Appointment-
From: Kang Xi [mailto:kang...@huawei.com]
Sent: Wednesday, August 30, 2017 10:44 AM
To: Kang Xi; onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; 
DAUGHERTY, ROBERT E; BULLARD, GIL; KLUGER, YOAV
Subject: [integration][so] vCPE workflow discussion
When: Wednesday, August 30, 2017 1:30 PM-3:00 PM (UTC-05:00) Eastern Time (US & 
Canada).
Where: https://zoom.us/j/44





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

Re: [onap-discuss] [integration][so] vCPE workflow discussion

2017-08-31 Thread BULLARD, GIL

Hey Yoav, Kang,
I think we need a meeting with A&AI and SDNC to work out the details, given the 
open issue with not knowing which component will be creating in A&AI certain 
cloud resources which may be needed to carry the MAC Address in the event.  
Note that now it will be a VNF and not a PNF that will be generating the event 
in A&AI, and I am concerned that sending a MAC Address (i.e., the correlation 
key for ROBOT) in a VNF event may be unnatural.
Gil

From: KLUGER, YOAV
Sent: Wednesday, August 30, 2017 6:10 PM
To: BULLARD, GIL ; Kang Xi ; 
onap-discuss@lists.onap.org; DAUGHERTY, ROBERT E 
Cc: ZINNIKAS, MICHAEL J 
Subject: RE: [integration][so] vCPE workflow discussion

Gil,

Are you saying that what is still missing are the exact format of the object in 
A&AI and the exact format of the event produced by A&AI when this object is 
updated? Or do you see something more than that which we still need to work out?

Thanks,
Yoav Kluger
Amdocs Technology
+1(201)912-7294
+972-54-4850278
[cid:image001.jpg@01D32237.7D9E2C20]


_________
From: BULLARD, GIL [mailto:wb5...@att.com]
Sent: Wednesday, August 30, 2017 5:49 PM
To: Kang Xi mailto:kang...@huawei.com>>; 
onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; DAUGHERTY, 
ROBERT E mailto:rd4...@att.com>>; Yoav Kluger 
mailto:yoav.klu...@amdocs.com>>
Cc: ZINNIKAS, MICHAEL J mailto:mz2...@att.com>>
Subject: RE: [integration][so] vCPE workflow discussion


Team,
I have updated the slides based upon the feedback today that modeling of BRG as 
a PNF will not be viable from an SO perspective in R1.  I have thus changed it 
to an Allotted Resource.  The updated slides can be found here:
https://wiki.onap.org/display/DW/Residential+Broadband+vCPE+Drafts+for+discussion?focusedCommentId=15991633&refresh=1504129602127#comment-15991633<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Residential-2BBroadband-2BvCPE-2BDrafts-2Bfor-2Bdiscussion-3FfocusedCommentId-3D15991633-26refresh-3D1504129602127-23comment-2D15991633&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6llaOBbLWNSasQ9_ejgubw&m=h9GVfp6z2th2TSAVfaP3qJBYEBW0QREHVllRpNC2GeY&s=n_GrAPikezVooDwmkncDlweM-GUAxKHFpPreLREEG0o&e=>

Comments are appreciated.

One issue we need to work is exactly which object SDNC will update in A&AI as 
part of the BRG Event processing flow, and what will the event look like that 
is intercepted by ROBOT.  We need to verify that Robot will be able to 
correlate this event.  I believe that this can be done because the event will 
have the BRG_EMU VNF UUID on it.
Thanks,
Gil


-Original Appointment-
From: Kang Xi [mailto:kang...@huawei.com]
Sent: Wednesday, August 30, 2017 10:44 AM
To: Kang Xi; onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; 
DAUGHERTY, ROBERT E; BULLARD, GIL; KLUGER, YOAV
Subject: [integration][so] vCPE workflow discussion
When: Wednesday, August 30, 2017 1:30 PM-3:00 PM (UTC-05:00) Eastern Time (US & 
Canada).
Where: 
https://zoom.us/j/44<https://urldefense.proofpoint.com/v2/url?u=https-3A__zoom.us_j_44&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6llaOBbLWNSasQ9_ejgubw&m=h9GVfp6z2th2TSAVfaP3qJBYEBW0QREHVllRpNC2GeY&s=dBfNEOF-qO9EqGQvpx_KRcfRd4R7MNi6ypt2YX8fSK4&e=>





This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at 
https://www.amdocs.com/about/email-disclaimer<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.amdocs.com_about_email-2Ddisclaimer&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6llaOBbLWNSasQ9_ejgubw&m=h9GVfp6z2th2TSAVfaP3qJBYEBW0QREHVllRpNC2GeY&s=A2me1wfp1c-6eDbGggypmIoV7yeCt36gfE0IY0dxsko&e=>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [integration][so] vCPE workflow discussion

2017-08-30 Thread BULLARD, GIL

Team,
I have updated the slides based upon the feedback today that modeling of BRG as 
a PNF will not be viable from an SO perspective in R1.  I have thus changed it 
to an Allotted Resource.  The updated slides can be found here:
https://wiki.onap.org/display/DW/Residential+Broadband+vCPE+Drafts+for+discussion?focusedCommentId=15991633&refresh=1504129602127#comment-15991633

Comments are appreciated.

One issue we need to work is exactly which object SDNC will update in A&AI as 
part of the BRG Event processing flow, and what will the event look like that 
is intercepted by ROBOT.  We need to verify that Robot will be able to 
correlate this event.  I believe that this can be done because the event will 
have the BRG_EMU VNF UUID on it.
Thanks,
Gil


-Original Appointment-
From: Kang Xi [mailto:kang...@huawei.com]
Sent: Wednesday, August 30, 2017 10:44 AM
To: Kang Xi; onap-discuss@lists.onap.org; DAUGHERTY, ROBERT E; BULLARD, GIL; 
KLUGER, YOAV
Subject: [integration][so] vCPE workflow discussion
When: Wednesday, August 30, 2017 1:30 PM-3:00 PM (UTC-05:00) Eastern Time (US & 
Canada).
Where: https://zoom.us/j/44





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

Re: [onap-discuss] {URGENT} RE: [so] Weekly Meeting

2017-08-15 Thread BULLARD, GIL

Seshu, I do not have an SO meeting on my calendar for Wednesday.  Is that an 
issue with my calendar, or has a meeting notice not been yet sent?
Thank you,
Gil

From: Seshu m [mailto:seshu.kuma...@huawei.com]
Sent: Thursday, August 10, 2017 12:44 AM
To: Kenny Paul 
Cc: Xinhui Li ; Danny Lin ; Jinxin (Saw) 
; Zengjianguo (OSS Design) ; Andrew 
Philip ; Yang, Bin ; 
zhanganb...@chinamobile.com; Ethan Lynn ; CHOMA, JOHN S 
; DeWayne Filppi ; Byung-Woo Jun 
; wangchen...@chinamobile.com; 
zhonghe...@boco.com.cn; zhang.zh...@zte.com.cn; Chenchuanyu 
; yangyan...@chinamobile.com; DAUGHERTY, ROBERT E 
; Lingli Deng ; 
wu.li...@zte.com.cn; yangyuan...@boco.com.cn; BULLARD, GIL ; 
denghui (L) ; Christopher Donley (Chris) 
; alex@intel.com; Vijaykumar S 
; onap-discuss@lists.onap.org; Praveen Krishnamurthy P 

Subject: RE: {URGENT} RE: [so] Weekly Meeting

Thanks for the resolution provided.
Could you also provide the access rights to record the meetings.

Best Regards,
Seshu
**
 This email and its attachments contain confidential information from HUAWEI, 
which is intended only for the person or entity whose address is listed above. 
Any use of the information contained here in any way (including, but not 
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is prohibited. If you receive this 
email in error, please notify the sender by phone or email immediately and 
delete it!

*

From: Kenny Paul [kp...@linuxfoundation.org]
Sent: Wednesday, August 09, 2017 11:29 PM
To: Seshu m
Cc: Xinhui Li; Danny Lin; Jinxin (Saw); Zengjianguo (OSS Design); Andrew 
Philip; Yang, Bin; 
zhanganb...@chinamobile.com<mailto:zhanganb...@chinamobile.com>; Ethan Lynn; 
CHOMA, JOHN S; DeWayne Filppi; Byung-Woo Jun; 
wangchen...@chinamobile.com<mailto:wangchen...@chinamobile.com>; 
zhonghe...@boco.com.cn<mailto:zhonghe...@boco.com.cn>; 
zhang.zh...@zte.com.cn<mailto:zhang.zh...@zte.com.cn>; Chenchuanyu; 
yangyan...@chinamobile.com<mailto:yangyan...@chinamobile.com>; DAUGHERTY, 
ROBERT E; Lingli Deng; wu.li...@zte.com.cn<mailto:wu.li...@zte.com.cn>; 
yangyuan...@boco.com.cn<mailto:yangyuan...@boco.com.cn>; BULLARD, GIL; denghui 
(L); Christopher Donley (Chris); alex@intel.com<mailto:alex@intel.com>; 
Vijaykumar S; onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; 
Praveen Krishnamurthy P
Subject: Re: {URGENT} RE: [so] Weekly Meeting
Hi Seshu,

Again my apologies for the inconvenience. The LF has added an additional Zoom 
host account to accommodate moving your meeting from Mondays to Wednesdays and 
I have made the necessary changes.  Please verify that the information in G-cal 
and on your meeting's wiki page are both correct.  As mentioned in my other 
email, please let me know the ticket number that was issued for your change 
request so that I can do some RCA. I do not want something similar happening to 
someone else.

Thanks.

Best Regards,
-kenny

Kenny Paul,  Technical Program Manager
kp...@linuxfoundation.org<mailto:kp...@linuxfoundation.org>
510.766.5945

On Aug 9, 2017, at 6:37 AM, Seshu m 
mailto:seshu.kuma...@huawei.com>> wrote:

Hi Kenny

As is discussed over the call, we are getting an issue in initiating the call,
We are getting the error
"The HOST has another meeting in progress"

I had been sending remainders and requests to re-schedule the bridge to 
wednesday, but that dint happen.
Kindly help us resolve this issue at the earliest possible time.
We are waiting

Best Regards,
Seshu
**
 This email and its attachments contain confidential information from HUAWEI, 
which is intended only for the person or entity whose address is listed above. 
Any use of the information contained here in any way (including, but not 
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is prohibited. If you receive this 
email in error, please notify the sender by phone or email immediately and 
delete it!

*

From: Seshu m [seshu.kuma...@huawei.com<mailto:seshu.kuma...@huawei.com>]
Sent: Wednesday, August 09, 2017 7:35 PM
To: Xinhui Li; Danny Lin; Jinxin (Saw); Zengjianguo (OSS Design); Andrew 
Philip; Yang, Bin; 
zhanganb...@chinamobile.com<mailto:zhanganb...@chinamobile.com>; Ethan Lynn; 
CHOMA, JOHN S; DeWayne Filppi; Byung-Woo Jun; 
wangchen...@chinamobile.com<mailto:wangchen...@chinamobile.com>; 
zhonghe...@boco.com.cn<mailto:zhonghe...@boco.com

Re: [onap-discuss] {URGENT} RE: [so] Weekly Meeting

2017-08-09 Thread BULLARD, GIL

sEshu, can you send out another zoom link while we wait for Kenny to respond?

From: Seshu m [mailto:seshu.kuma...@huawei.com]
Sent: Wednesday, August 09, 2017 9:38 AM
To: kp...@linuxfoundation.org
Cc: Xinhui Li ; Danny Lin ; Jinxin (Saw) 
; Zengjianguo (OSS Design) ; Andrew 
Philip ; Yang, Bin ; 
zhanganb...@chinamobile.com; Ethan Lynn ; CHOMA, JOHN S 
; DeWayne Filppi ; Byung-Woo Jun 
; wangchen...@chinamobile.com; 
zhonghe...@boco.com.cn; zhang.zh...@zte.com.cn; Chenchuanyu 
; yangyan...@chinamobile.com; DAUGHERTY, ROBERT E 
; Lingli Deng ; 
wu.li...@zte.com.cn; yangyuan...@boco.com.cn; BULLARD, GIL ; 
denghui (L) ; Christopher Donley (Chris) 
; alex@intel.com; Vijaykumar S 
; onap-discuss@lists.onap.org; Praveen Krishnamurthy P 

Subject: {URGENT} RE: [so] Weekly Meeting

Hi Kenny

As is discussed over the call, we are getting an issue in initiating the call,
We are getting the error
"The HOST has another meeting in progress"

I had been sending remainders and requests to re-schedule the bridge to 
wednesday, but that dint happen.
Kindly help us resolve this issue at the earliest possible time.
We are waiting

Best Regards,
Seshu
**
 This email and its attachments contain confidential information from HUAWEI, 
which is intended only for the person or entity whose address is listed above. 
Any use of the information contained here in any way (including, but not 
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is prohibited. If you receive this 
email in error, please notify the sender by phone or email immediately and 
delete it!

*

From: Seshu m [seshu.kuma...@huawei.com]
Sent: Wednesday, August 09, 2017 7:35 PM
To: Xinhui Li; Danny Lin; Jinxin (Saw); Zengjianguo (OSS Design); Andrew 
Philip; Yang, Bin; 
zhanganb...@chinamobile.com<mailto:zhanganb...@chinamobile.com>; Ethan Lynn; 
CHOMA, JOHN S; DeWayne Filppi; Byung-Woo Jun; 
wangchen...@chinamobile.com<mailto:wangchen...@chinamobile.com>; 
zhonghe...@boco.com.cn<mailto:zhonghe...@boco.com.cn>; 
zhang.zh...@zte.com.cn<mailto:zhang.zh...@zte.com.cn>; Chenchuanyu; 
yangyan...@chinamobile.com<mailto:yangyan...@chinamobile.com>; DAUGHERTY, 
ROBERT E; Lingli Deng; wu.li...@zte.com.cn<mailto:wu.li...@zte.com.cn>; 
yangyuan...@boco.com.cn<mailto:yangyuan...@boco.com.cn>; BULLARD, GIL; denghui 
(L); Christopher Donley (Chris); alex@intel.com<mailto:alex@intel.com>; 
Vijaykumar S; onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; 
Praveen Krishnamurthy P
Subject: [onap-discuss] [so] Weekly Meeting
When: Wednesday, August 09, 2017 9:30 PM-10:30 PM.
Where: Zoom
When: Wednesday, August 09, 2017 7:00 PM-8:00 PM (UTC+05:30) Chennai, Kolkata, 
Mumbai, New Delhi.
Where: Zoom

Note: The GMT offset above does not reflect daylight saving time adjustments.

*~*~*~*~*~*~*~*~*~*

[so] Weekly Meeting
https://zoom.us/j/309416964<https://urldefense.proofpoint.com/v2/url?u=https-3A__zoom.us_j_309416964&d=DwMFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6llaOBbLWNSasQ9_ejgubw&m=b2z7dsjTA3VVUoN1RKuPeinrEZKSB2OlCsEb1OINnCU&s=zPMNkixihBRI-8WaUlb090tlhcSdtcglPsBEAD1kL7o&e=>
Hi there,
ONAP Meeting 6 is inviting you to a scheduled Zoom meeting.
Join from PC, Mac, Linux, iOS or Android: 
https://zoom.us/j/309416964<https://urldefense.proofpoint.com/v2/url?u=https-3A__zoom.us_j_309416964&d=DwMFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6llaOBbLWNSasQ9_ejgubw&m=b2z7dsjTA3VVUoN1RKuPeinrEZKSB2OlCsEb1OINnCU&s=zPMNkixihBRI-8WaUlb090tlhcSdtcglPsBEAD1kL7o&e=>
 Or iPhone one-tap (US Toll): +14086380968,,309416964# or 
+16465588656,,309416964# Or Telephone: Dial: +1 408 638 0968 (US Toll) or +1 
646 558 8656 (US Toll) +1 855 880 1246 (US Toll Free) +1 877 369 0926 (US Toll 
Free) Meeting ID: 309 416 964 International numbers available: 
https://zoom.us/zoomconference?m=30xXqK2sdCwPiwKQZLwqW5yEWuwQ7QHT<https://urldefense.proofpoint.com/v2/url?u=https-3A__zoom.us_zoomconference-3Fm-3D30xXqK2sdCwPiwKQZLwqW5yEWuwQ7QHT&d=DwMFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6llaOBbLWNSasQ9_ejgubw&m=b2z7dsjTA3VVUoN1RKuPeinrEZKSB2OlCsEb1OINnCU&s=gJaETxMdJqKgtugSo_e34418dSzEwUFo7_GwGFbH9mc&e=>
1:30 PM - 2:30 PM UTC

Sorry about the timezone issue in the previous invite.

Best Regards,
Seshu
**
 This email and its attachments contain confidential information from HUAWEI, 
which is intended only for the person or entity whose address is listed above. 
Any use of the information contained here in any way (including, but not 
limited to, total or partial disclosure, reproduction, or dissemination) by 
p

Re: [onap-discuss] ONAP VoLTE SDC call

2017-08-04 Thread BULLARD, GIL

Team,
I posted to the VoLTE Use Case wiki (Drafts for discussion sub-page) an updated 
version of the PPT file that I quickly covered in today's call.  It contains a 
proposal on how to support this near term need that we face together.

Here is the link:
https://wiki.onap.org/display/DW/VoLTE+Drafts+for+discussion

I intend that this proposal has an advantage of minimizing rework and 
misalignment of Release 1 and Release 2.  Note the SO functionality in this 
proposal aligns with that which is being proposed in the vCPE Residential 
Broadband Use Case.

You will note that in this PPT I have also proposed a "design time" approach 
that results in a "flat" VoLTE model in the Release 2 timeframe through 
"compile time nesting".  Please do not conclude from this that I do not 
appreciate the business benefit of modeling in ONAP complex, multi-tiered 
services.  I do appreciate that need, and I agree that ONAP needs to be able to 
support such complex, "n-tiered" services.  In fact, I am proposing in this 
deck one way to accomplish such support, at least in the near term, by 
"flattening" the orchestration of such services.

Please also do not conclude from this "flattening" proposal that I am pushing 
back on the concept of "upper level" run-time service orchestration flows 
recursively delegating to "lower level" service orchestration flows, in an 
"n-tier" construct.   In fact, I find an attractive elegance to recursive flows 
like this.  However, I am proposing to avoid such an "n-tier" flow approach in 
the near term because I do envision that such an implementation would add 
significant complexity to ONAP orchestration "rainy day handling", certainly in 
trouble-shooting.  In addition, though I would like to see ONAP eventually 
support "rainy day handling" for such an "n-tier" orchestration architecture, I 
would prefer to first develop some underlying common "rainy day handling" 
infrastructure that each flow level can leverage.  I foresee that such a task 
will take some significant design work.  Because of that I propose the "compile 
time nesting" as a way to "flatten" the orchestration and to simplify this 
rainy day handling, at least in the near term "Release 2" timeframe.

I look forward to other's comments and feedback.
Gil Bullard
AT&T

-Original Appointment-
From: denghui (L) [mailto:denghu...@huawei.com]
Sent: Tuesday, August 01, 2017 11:44 AM
To: denghui (L); onap-discuss@lists.onap.org; onap-tsc
Subject: [onap-discuss] ONAP VoLTE SDC call
When: Wednesday, August 02, 2017 10:00 PM-11:00 PM (UTC+08:00) Beijing, 
Chongqing, Hong Kong, Urumqi.
Where: https://zoom.us/j/137904496


Hello all

This is for discussion ONAP VoLTE SDC call.

ONAP Meeting 5 is inviting you to a scheduled Zoom meeting.
Join from PC, Mac, Linux, iOS or Android: 
https://zoom.us/j/137904496
Or iPhone one-tap (US Toll): +14086380968,137904496# or +16465588656,137904496#
Or Telephone:
Dial: +1 408 638 0968 (US Toll) or +1 646 558 8656 (US Toll)
Meeting ID: 137 904 496
International numbers available: 
https://zoom.us/zoomconference?m=mi-ad1sMLWlXByAKLio5vDnd9JYqUR_a

Thanks a lot

DENG Hui
  << File: ATT1.txt >>

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

[onap-discuss] VoLTE Example Sequence Diagrams

2017-06-16 Thread BULLARD, GIL


ONAP Community,
I have posted to the VoLTE Use Case wiki comments a more detailed "Instantiate" 
sequence diagram view that illustrates an option to organize our SO internal 
structure, leveraging seed code that AT&T has provided into ONAP.

https://wiki.onap.org/pages/viewpage.action?pageId=3246140

The main SO participants shown are a "service level" workflow, refered to as 
the "E2E Service Level Workflow" in the diagrams, and a set of "VNF-level" 
workflow execution threads, each refered to as the "Create VNF Instance BB", 
where "BB" stands for "Building Block".   Each are based on generic SO BPMN 
such that their runtime behavior is model-driven, where the model is an 
instance structure derived from the corresponding VNF's TOSCA service template.

Recognizing that different Service Providers may want to model VoLTE 
differently, I have provided two different TOSCA modeling alternatives.  The 
sequence diagrams are organized according to these TOSCA models.  Note, 
however, that irrespective of the TOSCA model, the sequence diagrams look 
basically the same.  This is intended to illustrate the point that the 
workflows are intended to be implemented in a "generic" manner, and not 
specific to any particular Service or VNF type.  The model-driven behavior of 
ONAP as illustrated in the sequence diagrams would support either approach with 
no code impacts.

I apologize that you will find the post quite lengthy, but hopefully you also 
find that it adds value to the discussion.

Thank you,
Gil Bullard
AT&T


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

Re: [onap-discuss] Invitation: 5G Use Case Team Meeting @ Weekly from 8am to 9am on Thursday from Thu Jan 4 to Thu Dec 13 (PST) (onap-discuss@lists.onap.org)

Re: [onap-discuss] vCPE deep dive session in Paris

Re: [onap-discuss] [integration][so] vCPE workflow discussion

Re: [onap-discuss] [integration][so] vCPE workflow discussion

Re: [onap-discuss] [integration][so] vCPE workflow discussion

Re: [onap-discuss] [integration][so] vCPE workflow discussion

Re: [onap-discuss] [integration][so] vCPE workflow discussion

Re: [onap-discuss] [integration][so] vCPE workflow discussion

Re: [onap-discuss] {URGENT} RE: [so] Weekly Meeting

Re: [onap-discuss] {URGENT} RE: [so] Weekly Meeting

Re: [onap-discuss] ONAP VoLTE SDC call

[onap-discuss] VoLTE Example Sequence Diagrams

12 matches

Site Navigation

Mail list logo

Footer information