Just to be clear in my head: 1. In the ACK to the reservation request the Provider NSA will return the reservation ID it has associated with the new reservation. 2. The reservation confirm will still return the result of the reservation. 3. I will relax all requirements around UUID for those who hate to conform ;-) Sound correct? John. ----- Original Message -----
From: "Henrik Thostrup Jensen" <htj@nordu.net> To: "NSI Working Group" <nsi-wg@ogf.org> Sent: Wednesday, August 29, 2012 10:36:15 AM Subject: Re: [Nsi-wg] Addressing connections across requesters
Hi John
On Fri, 24 Aug 2012, John MacAuley wrote:
The only issue we have is that the RA will not know the connection ID so will not be able the query the reservation in its "reserving" state, or to see if it missed a confirmation message.
Yes, that is the main problem. However with solution A, we get into the issue that if a requester chooses the id, it does not know if the connection id is actually available (of course this can be reduced to a probability of essentially 0 - as long as everybody plays nice).
Perhaps, and I am just throwing it out there, we might consider reworking the ACK to the reserve.rq to return the allocated connection Id? Maybe a new mechanism?
I think this is good (I'm still not a fan of the RPC callback), but for what we have I think this is good.
Do we still need to have these as UUIDs? I am not against UUIDs, but I still do not see the point of forcing them at protocol level.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg