Generate connection IDs

[sajith]

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 to POST /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 and DELETE /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.

[italovalcy]

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 to POST /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 and DELETE /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.

[sajith]

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.

[italovalcy]

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:

1. When two different clients request different circuits but with the same connection ID, will SDX-Controller provide a API response that can differentiate that particular situation? This way the client will know that only the connection ID was duplicated and generate a new connection ID and try again.
2. Once we clarify the doubt above, should we have any number of maximum reretries a SDX-Controller client have to keep trying to create a new connection ID?
3. When a connection gets deleted, can the connection ID be reused ?

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?

[YufengXin]

@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.

[sajith]

@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:

1. SDX Controller should reject duplicates. (It doesn't do that right now AFAIK, but it should.)
2. Clients could use UUIDs, so that they don't have to re-try until they find a valid ID.
3. SDX Controller would be doing a DB lookup to detect duplicates. Since SDX Controller keeps records of past connections, IDs should not be reused.

[sajith]

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.