Determined from John Choma that the "Generic Service" flow does not call SNIRO and already accepts a "Cloud_Region" as input. This eliminates the need for a "Homing Emulator" for the 5 "Infrastructure Services".
Robot will remember the vGMUX Cloud_Region and can pass that into ONAP on the vCpeResCust Service Instantiation request. This eliminates the need for ONAP to do a lookup of the vGMUX Cloud_Region based on the vGMux_Infra Service Instance UUID. This is a good change for two reasons:
There is still an open issue as to which ONAP component will update the associations to make such a lookup possible.
This allows us to eliminate the need for the "Homing Emulator" to support the vCpeResCust Service Instantiation request.
The above resulted in the elimination of the need for a "Homing Emulator" altogether.
Here is a rough draft with the BRG being modeled as an Allotted Resource rather than as a PNF. The model changes are found throughout the deck, but the slides you will be most interested in are the general model (slides 4, 5, 6) and the impacted flows (slides 40, 41, 45). Any comments are appreciated.
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.
I've incorporated updates to the slide deck as follows:
Slide 4, the vCpeResCust model, remains as before, modeling the BRG as an Allotted Resource and not as a PNF.
Slide 40, however, has changed in the following ways:
In the Release 1 “Alt” flow, SDNC reverts to creating a PNF object in A&AI as I had showed before. However, this PNF object is not 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
SDNC searches A&AI for BRGs by searching for PNFs such that that MAC Address appears on a P-Interface of that PNF. (Proposal to add this attribute to A&AI P-Interface object.)
Slide 45 will change in the following ways:
SO passes the BRG_WAN_MAC_Address to SDNC with the “Assign” for the BRG Allotted Resource.
As part of “Assign” processing for the BRG AR, SDNC searches 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 treats the A&AI PNF object as the “pool” from which to assign the WAN IP for that Allotted Resource object.
For an Allotted Resource that consumes an entire VNF (as in this case), the Allotted Resource may not really need to be “created”; rather it pre-exists with the VNF instantiation. Thus, the “Create” operation on the Allotted Resource is changed to be a “no-op” and the “Activate” operation be what drives the configuration of the vBRG_EMU VNF.
I have updated the model section of the deck, including the summary table on slides 16, 17, and 18. Note that with the change to VNF-API the assignment of the "VNI Pool" for the vGMUX is no done at the VF Module level. Not sure if that matters or not, but now the custom vG DG will need to assign the vG's VNI from the pool found at the vGMUX VF Module rather than the VNF.
Updates slides based on recent issue resolutions. Particularly, the following updates:
1) As per discussions and decisions from early September, the vG configuration will be triggered via SO sending the VF Module-level "Activate" request to SDNC (as opposed to the VF-level "Activate" request).
2) As per discussions this week, the vG's IP address will be assigned as part of the TunnelXConn "Assign" request (as opposed to the vG "Assign" request).
These changes have been folded primarily into slides 19, 25, and 37. Also see slides 40-43 which capture the options we considered for the latter issue, settling on Option 3.
Updated to associate the BNG_MUX network with the vBngInfra Service, rather than being its own Service. The impacted slides are slides 3, 7, 10, 13, 18 and 21 to show this change in the association between Network and Service. In addition, slides 3, 10, 18 and 21 have been modified to show the updated sequencing of Robot activities. Note that slides have also been shifted in their sequences to more closely align with this updated Robot sequencing.
11 Comments
Gil Bullard
Draft vCPE Use Case Sequence Diagrams and Model...
Gil Bullard
Updated Slides. Let's discuss how to fold the information contained into the Wiki...
Gil Bullard
Updated slides based on review with SDNC Dan Timoney. We still need to discuss how to fold the information contained into the Wiki...
Gil Bullard
Updated slides based on the following:
Gil Bullard
Here is a rough draft with the BRG being modeled as an Allotted Resource rather than as a PNF. The model changes are found throughout the deck, but the slides you will be most interested in are the general model (slides 4, 5, 6) and the impacted flows (slides 40, 41, 45). Any comments are appreciated.
Gil Bullard
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.
Gil Bullard
I've incorporated updates to the slide deck as follows:
Gil Bullard
I have updated the model section of the deck, including the summary table on slides 16, 17, and 18. Note that with the change to VNF-API the assignment of the "VNI Pool" for the vGMUX is no done at the VF Module level. Not sure if that matters or not, but now the custom vG DG will need to assign the vG's VNI from the pool found at the vGMUX VF Module rather than the VNF.
Gil Bullard
Slide input for the Paris presentation...
Gil Bullard
Updates slides based on recent issue resolutions. Particularly, the following updates:
1) As per discussions and decisions from early September, the vG configuration will be triggered via SO sending the VF Module-level "Activate" request to SDNC (as opposed to the VF-level "Activate" request).
2) As per discussions this week, the vG's IP address will be assigned as part of the TunnelXConn "Assign" request (as opposed to the vG "Assign" request).
These changes have been folded primarily into slides 19, 25, and 37. Also see slides 40-43 which capture the options we considered for the latter issue, settling on Option 3.
Gil Bullard
Updated to associate the BNG_MUX network with the vBngInfra Service, rather than being its own Service. The impacted slides are slides 3, 7, 10, 13, 18 and 21 to show this change in the association between Network and Service. In addition, slides 3, 10, 18 and 21 have been modified to show the updated sequencing of Robot activities. Note that slides have also been shifted in their sequences to more closely align with this updated Robot sequencing.