[Nsi-wg] Addressing connections across requesters
Henrik Thostrup Jensen
htj at nordu.net
Thu Aug 23 04:25:01 EDT 2012
On Wed, 22 Aug 2012, John MacAuley wrote:
> LOL - I argued endlessly about this and gave up.
>
> I would rather have the provider return the new connectionId
So, 3 for solution B :-).
> So how does the UUID not work? You just need it to. E unique within the
> provider NSA to solve your problem do you not?
If you let the client generate the connection id, you have two choices:
1. Scope the connection id within the identity of requester nsa
This guaranties that the connection id is not taken, assuming the client
have not specified the connection id before (something might have gone
wrong and it tried to reserve again). This is what we have today.
Unfortunately referencing to connections created by other NSAs are rather
tricky / messy.
2. Let the client use its specified connections id if it is not taken
(solution A).
In theory, UUIDs should work here assuming everything uses
them correctly. However as we have a protocol, I just see the UUID as a
format, and not as a way of generating non-clashing identifiers. There are
some slighly tricky problems concerning if it is allowed to reuse
connection ids for re-reservation with this, but nothing major.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net>
Software Developer, NORDUnet
More information about the nsi-wg
mailing list