Cong tested and reports following:
It seems there needs consensus on the interface_id, which is the OF id from Kytos now. The SDX middleware is neutral on this, but it's really about what you want the end user sees and uses to specify the end points of a request.
curl -H 'Content-type: application/json' 'http://3.218.56.104:8181/api/kytos/mef_eline/v2/evc/' -d '{"name": "AMLIGHT_vlan_10001_10001", "dynamic_backup_path": true, "uni_a": {"tag": {"value": 107, "tag_type": 1}, "interface_id": "aa:00:00:00:00:00:00:03:50"}, "uni_z": {"tag": {"value": 107, "tag_type": 1}, "interface_id": "aa:00:00:00:00:00:00:01:40"}}'
But the interface_id is strange, And does not accept our sample topology (below).
{"name": "AMLIGHT_vlan_10001_10001", "dynamic_backup_path": true, "uni_a": {"tag": {"value": 107, "tag_type": 1}, "interface_id": "urn:sdx:port:amlight.net:B1:2"}, "uni_z": {"tag": {"value": 107, "tag_type": 1}, "interface_id": "urn:sdx:port:amlight.net:B2:3"}}
it says this:
{"description":"The request body contains invalid API data. 'urn:sdx:port:amlight.net:B1:2' does not match '^([0-9A-Fa-f]{2}[:-]){8}(\\d{1,5})
Cong tested and reports following:
It seems there needs consensus on the interface_id, which is the OF id from Kytos now. The SDX middleware is neutral on this, but it's really about what you want the end user sees and uses to specify the end points of a request.
But the interface_id is strange, And does not accept our sample topology (below).
{"name": "AMLIGHT_vlan_10001_10001", "dynamic_backup_path": true, "uni_a": {"tag": {"value": 107, "tag_type": 1}, "interface_id": "urn:sdx:port:amlight.net:B1:2"}, "uni_z": {"tag": {"value": 107, "tag_type": 1}, "interface_id": "urn:sdx:port:amlight.net:B2:3"}}
it says this:
{"description":"The request body contains invalid API data. 'urn:sdx:port:amlight.net:B1:2' does not match '^([0-9A-Fa-f]{2}[:-]){8}(\\d{1,5})