Open sajith opened 6 months ago
It will be useful if SDX Controller can generate connection IDs when a
POST /connection
request is made, perhaps in the form of UUIDs. This way we can keep a better record of all the connection requests (including failed ones and successful ones) and perhaps more details like reason for failure. So the response toPOST /connection
should be in the form of (just an example; we can figure out what useful information we can send eventually):{ "connection_id": "99f04453-fca1-4a5c-8454-ec5bb70fb04f", "status": "OK", "details": "Connection requests have been published" }
Why UUIDs? We currently assume that connection IDs are integers (in
GET /connection/:connection_id
andDELETE /connection/:connection_id
), but it would be difficult to maintain unique connection IDs that way across restarts. Using UUIDs as connection IDs should solve that problem.Corresponding changes would be:
GET /connection/:connection_id
would need to handle the UUID generated above.DELETE /connection/:connection_id
would pass the UUID to PCE so that PCE can tear down the internal states it made during connection setup. This obviously calls for corresponding changes in PCE.
Hi @sajith great point! I totally agree with you that it would be much better if the SDX-Controller generates the connection_id and using the UUID seems to be the best option.
Hi @sajith great point! I totally agree with you that it would be much better if the SDX-Controller generates the connection_id and using the UUID seems to be the best option.
There's been a change of heart since this issue was written up though... :-)
My understanding now is that it should be SDX Controller's clients (namely Meican or some other API client) that should generate a unique connection IDs for each connection request. Connection requests already carry a id
field, and it is required.
SDX Controller should simply reject connection requests with duplicate IDs. The IDs can be UUIDs or some other unique strings (formed from submitter + their domain + timestamp, or a hash of it, for example). The actual ID should not matter as long as it is unique.
Hi @YufengXin , @congwang09 and @sajith since the idea now is that SDX-Controller clients should be the ones generating the connection ID, I have a few comments/doubts that I would like to hear your opinion:
Finally, just out of curiosity, what would be the advantage of delegating the responsibility of generating unique connection identifiers for the Client (in a multi-client platform) instead of the SDX-Controller taking care of this?
@italovalcy Very good points. Thanks. @congwang09 knows better about the details: 1, 2, and 3 are necessary.
The last: the original logic was: if connection.id exists, take it, else: the server generates an uuid to assign. (1) the specification has the id attribute as a required; (2) (in our internal discussion, we said in general web application, the server side generates the resource id.) Now I think the 'else' statement is skipped.
We can finalize the decision after the first round of test passes since the Meican generates the id already.
@italovalcy If I understand correctly, the requirement for connection IDs is to be globally unique, and nothing much else. Connection requests are required to carry an ID right now, or they will be rejected by validation step, even before they get to the methods that handle them. To answer your questions:
Finally, just out of curiosity, what would be the advantage of delegating the responsibility of generating unique connection identifiers for the Client (in a multi-client platform) instead of the SDX-Controller taking care of this?
There is no particular advantage to one party or the other generating connection IDs. There simply should be an agreement that IDs are required to be globally unique (as far as one SDX Controller instance is concerned), and who should generate it.
Clients generating an ID would be the path of least resistance though, because that was the assumption when connection request format was initially made, and that is the assumption SDX Controller, PCE, and datamodel are operating with.
It will be useful if SDX Controller can generate connection IDs when a
POST /connection
request is made, perhaps in the form of UUIDs. This way we can keep a better record of all the connection requests (including failed ones and successful ones) and perhaps more details like reason for failure. So the response toPOST /connection
should be in the form of (just an example; we can figure out what useful information we can send eventually):Why UUIDs? We currently assume that connection IDs are integers (in
GET /connection/:connection_id
andDELETE /connection/:connection_id
), but it would be difficult to maintain unique connection IDs that way across restarts. Using UUIDs as connection IDs should solve that problem.Corresponding changes would be:
GET /connection/:connection_id
would need to handle the UUID generated above.DELETE /connection/:connection_id
would pass the UUID to PCE so that PCE can tear down the internal states it made during connection setup. This obviously calls for corresponding changes in PCE.