Hello Henrik, Welcome to the NSI discussions, here are some thoughts on your feedback: 1. the four messages described are not as illogical as they first appear. Please be aware that there can be a long delay between a reserveRequest and reserveConfirmed/failed so a quick acknowledgment of the receipt of the reserveRequest is useful. 2. In general I agree that the pathObject does not fit well with the serviceParameters 3. I will check and make sure these are made consistent 4&5. I have not strong feeling on this point - others may like to comment. Guy -----Original Message----- From: nsi-wg-bounces@ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of Henrik Thostrup Jensen Sent: 13 July 2011 12:17 To: NSI Working Group Subject: [Nsi-wg] Feedback for WS protocol Hi everyone (I'm the NORDUnet developer creating the OpenNSA NSI implementation). (Also, please ignore a potential double post due to wrong sender email) I have some feedback/changes/wishes/questions for the WS-rendering of the NSI protocol. 1. Odd request/reply structure. The request/reply structure is somewhat odd. It seems that for every request there is an message to imply that the message itself has been received as well as the actual response, which also has a response. I.e., the interaction will look like this for a reservation (AFAICT) A -> B: reserveRequest A <- B: reserveResponse A <- B: reserveConfirmed A -> B: reserveConfirmedResponse This means that 4 messages are exchanged, when 2 would be enough. This is silly in my opinon, and only adds complexity to the implementation without adding any value. Also, at some point in time the reserveResponse and reserveConfirmed will get reordered as they don't have any ordering between them, meaning the requester will have to understand that case. It also seems to against the spec, which defines the primitives reserveRequest, reserveConfirmed, and reserveFailed. 2. Moving pathObject out of ServiceParameters I would very much like to move pathObject out of serviceParameters and into the top-level attributes. As a reservation is created the pathObject send around changes, where as the rest of the ServiceParameters does not. This also reflects itself in data structures where this becomes somewhat backwards to keep track of the path in aggregate connections. It is of course completely possible to keep the current structure, but it would simplify the implementation to move the path out of the service parameters. Also: Rename pathObject to path everywhere. We do not put the object suffix on other things either. Also(2): Rename OrderedStpListType to StpListType in spec. and protocol. A list is by definition ordered, otherwise it would be called a multiset or bag. 3. Protocol service parameters differ spec service parameters In the spec. schedule is in service parameters, in the WS protocol it is in the ReservationRequestType. I don't have any strong opions on where it should be, but I think it should be consistent. Somewhat similarly the spec. has guarenteed and preferred under serviceAttrs (which is under ServiceParameters). In the WS protocol guaranteed and preferred are directly under ServiceParameters. Again I don't have any strong opions on what is correct, but I think it should be consistent. 4. The transactionId The transactionId is not mentioned in the spec., but is used to denote session due to SOAPs lack of it. Could we call it something less misleading? It has nothing to do with transactions. E.g., sessionId, requestId (i prefer the latter as a session could technically consist of several requests). 5. Inconsistent path description The spec. introduces the notion of a service demarcation point as a pair of connected STPs. Could we introduce this type (essentially a tuple/struct/complextype with two STPs), and use it for describing paths, such that a path is a (sourceSTP, destSTP, SDPList). Best regards, Henrik Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg

Responses in-line. One note - keep a clear mental separation of the XSD and the WSDL. The XSD represents the generic modelling of the NSI protocol independent of transport. The WSDL attempts to provide an instance of reliable transport for implementation prototyping. On 2011-07-13, at 7:16 AM, Henrik Thostrup Jensen wrote:

Hi everyone

(I'm the NORDUnet developer creating the OpenNSA NSI implementation). (Also, please ignore a potential double post due to wrong sender email)

I have some feedback/changes/wishes/questions for the WS-rendering of the NSI protocol.

1. Odd request/reply structure.

The request/reply structure is somewhat odd. It seems that for every request there is an message to imply that the message itself has been received as well as the actual response, which also has a response. I.e., the interaction will look like this for a reservation (AFAICT)

A -> B: reserveRequest A <- B: reserveResponse A <- B: reserveConfirmed A -> B: reserveConfirmedResponse

This means that 4 messages are exchanged, when 2 would be enough. This is silly in my opinon, and only adds complexity to the implementation without adding any value. Also, at some point in time the reserveResponse and reserveConfirmed will get reordered as they don't have any ordering between them, meaning the requester will have to understand that case. It also seems to against the spec, which defines the primitives reserveRequest, reserveConfirmed, and reserveFailed.

You are correct. Four messages will be exchanged per request/confirmed/failed interaction, however, these are only two operations from an XSD perspective. Remember to separate the NSI operations from the WSDL transport. The reservationRequest is carried across in a SOAP POST operation, it gets accepted on the remote NSA, and the remote NSA returns either reservationResponse or SOAP fault in the POST result. We need this reservationResponse to acknowledge the remote NSA has received the reservationRequest otherwise we will keep trying to send. This request/acknowledgement model was needed to address the requirement that many of the NSI operation are long duration, taking seconds to minutes, to days for the confirm/failed response to return. For any reasonable error handling to be achieved we needed to introduce an acknowledgement of some type. The GenericResponseType message returned as the acknowledgement is an empty sequence, but at least provides a positive indication that the request was received (hmmm... I had transactionId in there at one point - I might put it back in). Can I get a confirm back before the the ack for the request? Yes you could depending on the remote NSA design but this is not an issue since the transactionId models the request/confirm/failed interaction, so I can easily handle this in software logic. If I had been doing the NSI protocol from scratch as an web service it would be quite different. Doing the generic abstract protocol first is always tough for implementation given you end up with the worse of both worlds :-)

2. Moving pathObject out of ServiceParameters

I would very much like to move pathObject out of serviceParameters and into the top-level attributes. As a reservation is created the pathObject send around changes, where as the rest of the ServiceParameters does not. This also reflects itself in data structures where this becomes somewhat backwards to keep track of the path in aggregate connections. It is of course completely possible to keep the current structure, but it would simplify the implementation to move the path out of the service parameters.

We placed the path object into the service parameters is part of the specific service attributes used to guide the service request, and therefore, seemed relevant with other service specific attributes. I don't specifically understand your concerns with respect to implementation, but you are probably further along than I am. I think we will need to get additional input from the team.

Also: Rename pathObject to path everywhere. We do not put the object suffix on other things either.

Yes, I agree with this.

Also(2): Rename OrderedStpListType to StpListType in spec. and protocol. A list is by definition ordered, otherwise it would be called a multiset or bag.

Yes.

3. Protocol service parameters differ spec service parameters

In the spec. schedule is in service parameters, in the WS protocol it is in the ReservationRequestType. I don't have any strong opions on where it should be, but I think it should be consistent.

Somewhat similarly the spec. has guarenteed and preferred under serviceAttrs (which is under ServiceParameters). In the WS protocol guaranteed and preferred are directly under ServiceParameters. Again I don't have any strong opions on what is correct, but I think it should be consistent.

I believe we made a change that was probably not captured in the document.

4. The transactionId

The transactionId is not mentioned in the spec., but is used to denote session due to SOAPs lack of it. Could we call it something less misleading? It has nothing to do with transactions. E.g., sessionId, requestId (i prefer the latter as a session could technically consist of several requests).

The transactionId is for an NSA to correlate a request to a confirm/failed. If you get a confirm or failed back before the ack to the request then you can still correlated it based in transactionId. The transactionId does not represent a session. Only a single message exchange between a pair of NSA. I have baounce

5. Inconsistent path description

The spec. introduces the notion of a service demarcation point as a pair of connected STPs. Could we introduce this type (essentially a tuple/struct/complextype with two STPs), and use it for describing paths, such that a path is a (sourceSTP, destSTP, SDPList).

I will need to have a look at this part of the document..

Best regards, Henrik

Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg