...
Since we are running a mock PCE server, it is important to use the exact endpoint names as this PCE server expects to receive. Therefore, a user needs to make sure that the endpoint names created in previous steps mentioned in reference (*) below, are with these names:
UI Operation Guidance for Guilin
- For Domain A:
- tranportEp_src_ID_111_1
- tranportEp_src_ID_111_2
- tranportEp_src_ID_114_1
- For Domain B:
- tranportEp_src_ID_212_1
- tranportEp_src_ID_214_1
- tranportEp_src_ID_212_2
The recommended way to create the endpoints is doing it manually using the postman collection provided in this wiki page. This postman collection does have the required payloads for each of these endpoints (i.e. networkroutes). The payloads have correct "next-hop" values for each of these 6 endpoints. These "next-hop" values are based on our two topologies. Included in this postman collection is the URL and the payload required to create 3 logical links that are connecting these 6 endpoints, however, you do not need to create these logical-links manually because SO creates them for you. You only need to do it manually if you are not testing with SO and instead, you are calling SDNC directly (no SO involved). Please see the postman collection for details.
| View file | ||||
|---|---|---|---|---|
|
However, if a user needs to create them using the UUI way described in reference below, make sure to use the following values for AN and CN respectively:
UI Operation Guidance for Guilin
- AN: networkId-providerId-10-clientId-0-topologyId-2-nodeId-10.1.1.1-ltpId-512
- CN: networkId-providerId-20-clientId-0-topologyId-2-nodeId-10.2.1.2-ltpId-512
After you created the endpoints for AN and CN as stated above, the outcome is a logical-link that gets created in your AAI. Find which “logical-link” is created in your AAI: You can retrieve all of your logical-links by sending a GET request to your AAI:
- curl -k -u "AAI:AAI" -H "X-FromAppId:AAI" -H "Content-Type:application/json" -H "Accept: application/json" -H "X-TransactionId:99999" -X GET https://{{k8s}}:30233/aai/v21/network/logical-links
Among all the logical-links that you have in your AAI, find the logical-link that is created as a result of your UUI creation. This should be the one that has “TsciConnectionLink” as its link-type attribute.
Now the last step is to configure your mock PCE server (PCE.zip), to expect your newly created logical-link “link-name” attribute as a query parameter instead of the mentioned “tranportEp…”. To do so, find the file named config.json included in the following directory of this PCE.zip file: "./moco/Stubs/testcase/gso", and replace the “tranportEp_src_ID_111_1” query parameter with the new logical-link link-name uuid. Then re-run the java file for this mock PCE server to pickup the change.
Note 2: ESR registration of the third-party domain controllers and topology discovery operation
...
Once a third-party controller is being registered in ONAP, a "Topology Discovery" operation will be triggered and the domain controller will be called in order to retrieve the topology. SDNC then, will store the topology in AAI. Please follow the instructions written below in Note 3, for this ESR registration.
Note 3: A known issue with ESR registration of a 3rd party domain controller
The following photo shows the details of a 3rd party controller when a user is registering it in ESR portal. Adjust the URL info accordingly. The password to be used is "rocks" if you use ACTN simulator. There is a known issue in ESR portal which requires a quick fix in one of the DGs so that the topologies can be discovered properly. The issue is about the values shown in the registration web form under the attribute "Type". As can be seen in the following photo, the available types in ESR portal are either WAN or DC, however, SDNC discovery DG expects SOTN so that it can discover the topologies from the ACTN simulators. To fix this issue, please follow the following quick steps:
- Download the json file of the DG (directed graph) that is responsible for topology discovery from the following link:
- Modify this json file by changing the value of SOTN to WAN. SOTN value is in line 415 and 416 of the above file.
- You now need to upload this modified version of the DG into your system. This can be done using the dgbuilder graphical tool, available for us by ONAP to be used. This dgbuilder tool can be accessed by the following URL:
- https://{{k8s}}:30203 or http://{{k8s}}:30203, in case you cannot access it by https.
- once prompted, the default username/password for the dgbuilder tool is: dguser/test123
- You now need to import your modified version of the DG explained above into your dgbuilder. To do so, copy the contents of the modified DG's json file into your clipboard, and from the menu on the top right corner of the dgbuilder tool, click on "import" → "clipboard" and paste the contents of your clipboard into the box and click ok. See this photo for details:
- After importing the graph into the dgbuilder graphical tool, you need to "upload" it into your system/sdnc. To do so, click on the small square box next to the first node called "DGSTART", then click on "Upload XML", and then click on "VewDGList", and then make sure to "Activate" this modified version of the DG that you just uploaded. This is usually shown by "${project.version}" as its version.
- That's it! You now have a modified version of the discovery DG that expects to receive "WAN" from ESR as a type, instead of the mentioned "SOTN".
Note 4: A known issue with "delete slice" operation
...