[Nsi-wg] Addressing connections across requesters

[John MacAuley]

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 at nordu.net>
> To: "NSI Working Group" <nsi-wg at 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 at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg
>